BitcoinTalk
Hostnames instead of IP Addresses

View all posts

External link

The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled.

The future plan for sending to an IP is to make it a bitcoin address plus IP, like:

1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com

I need suggestions for the separator character.  ":" is a candidate, but IPv6 has : in it and that might get confusing.  Something that's allowed in url parameters would be nice.

I want to use SSL for the connection, using the bitcoin address' public key as the cert.  You would be certain you're connected to who you thought, and safely encrypted.  The bitcoin address would not be used for the transaction, only for authentication.  A new generated bitcoin address would be sent through the SSL connection.

Since it's authenticated, it would then be safe to allow the IP address to be a domain name.  Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.
SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to.  This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.

Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.

The user would send to domain.com (or www.domain.com is ok too).  That would be very natural and users could see and verify that what they entered is who they intend to pay.

The SSL also makes it safe for TOR users.

Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for.  You simply cannot count on users to enter the right thing in the comment fields to identify the transaction.  It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.

Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability.  Regular users aren't used to the idea of having to identify the payment.  Merchants would get too many blank payments followed by "I paid you, where's my stuff?!" a week later.

The payment sequence does have a step where the receiver verifies the order before accepting it.  It can reject the payment and return an error message if it doesn't contain a valid order number.  That would require a difficult level of integration of custom code with the bitcoin server though.