Most solutions only work with a single Bitcoin address (terrible for
privacy, and also potentially a security risk) or xpubkey (also terrible
I think the best solution here is some kind of store-and-forward server,
where you trade a little bit of privacy (to the server, that is), but get
the convenience of using (for example) an email address as the account.
I like for example BIP75 for this, and I hope the community can work
towards a solution like this. This could potentially work good with LN as
2017-12-19 10:05 GMT+01:00 Damian Williamson via bitcoin-dev <
> There is no reason it should not be easily possible to develop a Bitcoin
> wallet that has an integrated name to address mapping feature. It might be
> a good idea for a software product, it could even be based on Bitcoin Core.
> There is no specific reason that people wanting that sort of feature could
> not use it. In fact, you could map names, strings, email addresses, it
> could be very flexible.
> Relying on an additional service like DNS which is flexible enough to
> handle the job, does introduce an additional availability risk. There is no
> additional privacy risk provided each mapped name or address is only used
> once to send/receive one payment unless you directly use something
> personally identifiable like an email address which could be used to map
> bitcoin addresses to an individual. Personally, I am not concerned about
> privacy so much but can understand that some highly value their privacy.
> If you get it right it will be a service better than namecoin transacting
> in Bitcoin. If you think that is valuable, go for it.
> Damian Williamson
> *From:* firstname.lastname@example.org <
> email@example.com> on behalf of Sjors
> Provoost via bitcoin-dev <firstname.lastname@example.org>
> *Sent:* Monday, 18 December 2017 10:26 PM
> *To:* Douglas Roark; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet
> Have you thought about combining this with BIP-47? You could associate
> payment codes with email via DNS.
> It would be nice if there was a way to get rid of the announcement
> transaction in BIP-47 and establish a shared secret out of bound. That
> would simplify things, at the cost of an additional burden of storing more
> than an HD seed to recover a wallet that received funds this way.
> Perhaps the sender can email to the recipient the information they need to
> retrieve the funds. The (first) transaction could have a time locked refund
> in it, in case the payment code is stale.
> > Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev <
> email@example.com> het volgende geschreven:
> > On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
> >> I was wondering in terms of mass adoption, instead of long wallet
> >> addresses, maybe there should be a DNS-like decentralized mapping
> >> service to provide a ***@crypto address?
> > A few years ago, I was part of an effort with Armory and Verisign to
> > make something similar to what you're describing.
> > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> > find the one and only official draft. I worked on a follow-up with some
> > changes and some nice appendices, explaining some nice tricks one could
> > use to make payment management flexible. For various reasons, it never
> > got published. I think it's an interesting draft that could be turned
> > into something useful. Among other things, it was able to leverage BIP32
> > and allow payment requests to be generated that automatically pointed
> > payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> > it's as the easiest way to bootstrap identity to a common, reasonably
> > secure standard.
> > --
> > ---
> > Douglas Roark
> > Cryptocurrency, network security, travel, and art.
> > https://onename.com/droark
> > ***@vt.edu
> > PGP key ID: 26623924
> > _______________________________________________
> > bitcoin-dev mailing list
> > firstname.lastname@example.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> bitcoin-dev mailing list