Friendly bitcoin addresses

[phedny]

A nice idea I just thought about that would make adoption of bitcoin easier: add an email address to bitcoin address mapping. This would allow people to send bitcoins to an email address (like PayPal).

One way to do this would be a central database, but I guess this is not what we want, since the decentralized nature of bitcoin would not really align.

Another way might be to somehow put the mapping inside the blocks, such that it is public.

The method I would prefer is using DNS, combined with some service. For example, for the email address name@domain.com, bitcoin could lookup the SRV record _bitcoin._tcp.domain.com and connect to the listed server to request the bitcoin address of that user.

The separate service might even be dropped and all data be put in DNS. Looking up name@domain.com could lookup, say, name._bitcoin.example.com and the bitcoin address could be stored in a TXT record. Disadvantage of this method is that any modifications must be done directly into DNS.

These were just some ideas. Would be nice to read the opinion of other people on this one.

[Luke-Jr]

Since addresses are per-transaction and not per-user, it really doesn't make sense to do it in just DNS. A simple HTTP protocol could query http://domain/bitcoinaddress?comment=hi+there and get a text/plain address back (while the server-side script makes a db entry of the comment)

[phedny]

You are right, Luke-Jr. In most cases you'd probably want a different address for new transactions.

There are some use cases I was inspired by:
- Some some people (and websites) publish a bitcoin address where you can send donations; it would be much nicer if those are human-readable, instead of some kind of "garbage".
- In online (chat / forum) communication, copy/paste is available, but a human friendly address is much easier to use when communicating over the phone.

Now, taking your comment into account, I propose the following scheme:

- In DNS, publish the location of your mapping server, e.g. a _bitcoin._tcp.example.com SRV record
- This SRV record points to a mapping service, which accepts TCP connections
- The mapping service has a pool of addresses for each user it knows
- As a sender, you can connect to the mapping service, send the request "Give me an address for user@example.com" and you'll get a bitcoin address returned
- As the owner of the address, you can connect to the mapping service, send the request "Update my address pool. This is the new set of addresses you must use. This message is signed by the private key attached to one of my addresses you currently know of" and the server will update the pool.

This would allow administrators of a domain name to set up the server, set up DNS, for each user manually enter a single address and after that, the system can be used zero-config by senders and also by the user itself to update. The update could be added in the bitcoin clients, such that it automatically updates the address pool when it detects the addresses have been used.

A variant: instead of an SRV record and a TCP service, another kind of record (maybe TXT) could be used that points to the HTTP address of a webservice, the way Luke-Jr uses in his post.

[Matt Corallo]

See pull request here: https://github.com/bitcoin/bitcoin/pull/174

[kseistrup]

The separate service might even be dropped and all data be put in DNS. Looking up name@domain.com could lookup, say, name._bitcoin.example.com and the bitcoin address could be stored in a TXT record. Disadvantage of this method is that any modifications must be done directly into DNS.

A NAPTR record is probably more suitable for this kind of job, since you can use it to store all kinds of addresses.  This is already in production for e.g. ENUM (E.164 number mapping) and various address services.  For an example, look up the NAPTR of telnic.tel.

Cheers,

[phedny]

I like the comment kseistrup made. I've seen NAPTR records before, but never worked with them, so I didn't think about them. Using NAPTR I guess it would even be possible to have both the DNS-only and the server-based solution together.

E.g. looking up NAPTR user._bitcoin.example.com could result in either a "bitcoin" (or "E2U+bitcoin"?) service name with directly a bitcoin address or a "bitcoinmapper" service name with the URL of the mapper. The last one could be combined with a catchall RR (*._bitcoin.example.com) if example.com is a service provider that doesn't want to put everything in DNS. For users with their own domain name, they might decide to use the first type.

@BlueMatt: Nice one, I didn't find this request before. I even see that the discussion about security is already raised at that place. The problem with both DNSSec and HTTPS is that we must rely on trusted authorities. In case of DNSSec, we must rely on the TLD authority (Verisign for .com, SIDN for .nl) to not fake our own domain key. In case of HTTPS, we must rely on CAs like Verisign (or Comodo...) to do proper validation.

Maybe we must decide we can only rely on this mechanism for "normal" commercial activity (we must rely on SSL certs and banks anyway as it is right now). People that want to transfer bitcoins without wanting to rely on these parties can always keep using direct bitcoin addresses.

[Matt Corallo]

@BlueMatt: Nice one, I didn't find this request before. I even see that the discussion about security is already raised at that place. The problem with both DNSSec and HTTPS is that we must rely on trusted authorities. In case of DNSSec, we must rely on the TLD authority (Verisign for .com, SIDN for .nl) to not fake our own domain key. In case of HTTPS, we must rely on CAs like Verisign (or Comodo...) to do proper validation.

The problem is, your solution isn't secure either.  Your DNS resolver can easily change what you get as a response (or any MITM attacker for that matter) which means using DNS is highly insecure.  DNSSec helps somewhat, but MITM attackers between your dns resolver and you can still easily insert non-signed responses which point you to a different address.  HTTPS is much better as it doesn't fail open (ie if you get HTTP instead of HTTPS, you can easily reject the response without reimplementing an entire DNS resolver in Bitcoin).  In any system to use friendly addresses you have the issue of bootstrapping trust.  The way to solve that is a central authority like CAs or DNSSec at your TLD and there is no point reinventing the wheel here, just stick with the existing CA/DNSSec system.

[genjix]

This feature is https://github.com/bitcoin/bitcoin/pull/169

been there for 10 days so far.

[kseistrup]

E.g. looking up NAPTR user._bitcoin.example.com could result in either a "bitcoin" (or "E2U+bitcoin"?) service name with directly a bitcoin address or a "bitcoinmapper" service name with the URL of the mapper.

Or even just lookup NAPTR for user.example.com in the case of user@example.com and look for the proper E2U mapping.

Cheers,