Hostnames instead of IP Addresses

[SirArthur]

At least the Windows client seams unable to resolve hostnames - or doesn't even try, pops up an "Invalid Address" right away.

This is a huge setback taken most people have dynamic IP Addresses. Therefore, instead of "123.123.123.123" only it should be added the hability to send also to "someone-accepting-bitcoins.somedomain.sometld".

[Xunie]

Or it should just look the hostname up before it dismisses it as an invalid address.
This has probably just slipped the mind of the developer.

[laszlo]

There are security implications with sending payments to a 'hostname' instead of an internet address.  TCP is difficult to forge, however DNS is trivial.  It is not a good idea to send payments to a hostname.  Whether it is an oversight or intentional, it probably should not be used for anything where fraud is a concern.

Here's something I quickly googled up for anyone interested: http://adventuresinsecurity.com/Papers/DNS_Cache_Poisoning.pdf

It is not even really an attack, it's just how it works..  This is why once people figured out that DNS was unreliable, things like .rhosts for rsh went out of style and ssh uses public keys instead.  It still does some DNS checking to see if the key changed, which could indicate that the DNS has been used to divert your connection to another host.

It is very easy for me to make your computer think that someone-accepting-bitcoins.somedomain.sometld is MY computer, especially if I know you will be sending payment to it.. however if somedomain.sometld is some popular well known service like an exchange, I can just go trying to poison every bitcoin user's cache randomly and see how many I get.  I know every node's network address so I can figure out who their provider is, thus I can easily narrow down which recursors they're likely to be using, so it makes attacking it a lot nicer rather than blindly messing with a bunch of random resolvers that may or may not have any effect.

Many internet DNS servers will just accept any random data you send them, though there have been attempts to patch these things and work around some of the really trivial attacks.  In the end though, it is the DNS protocol that's at fault and it is not easily patchable without replacing it.  There are things in the works to make the protocol more secure and such, but until it's adopted by the entire internet, there will always be places to mess with it.

It is not even a good idea to send payment to an internet address in my opinion, because the way it is implemented in bitcoin right now, you don't know if you connected to the right node.  There is no pre-shared password or public key to verify manually.  While it is not feasible to take over an existing TCP connection, it is possible to use NAT to divert it.  In this case the attacker would have to have control of a router along the way to your destination, but in the case of Tor anyone can run an exit node and just accept all the bitcoin payments.. it's really easy to do that because they're all on port 8333 so I can just DNAT every connection to 8333 to my own bitcoin host.

Just don't use hostnames or internet addresses - use bitcoin addresses.

[SirArthur]

Here we go again...

YES, you can be phished, hijacked, whatever... but, again, it has to rely on informed options rather than behaviors of "I decided this is more secure to you".

[laszlo]

I'm not sure what you mean by again (I'm not the developer)..  anyway I'm just trying to explain why I don't think you should use it to accept payments.  Sending payments to a hostname is not reliable for the reasons I said above, and the biggest problem is that there is no way to even know that the payment went to the wrong place, for the sender.  There is a better (reliable) alternative using one time bitcoin addresses.

What I was getting at is that there is no authentication and no way to know if the payment got there with internet address based transactions.  I think the internet address based payments are only for testing locally.  The option is there but I don't think it's suitable for using on the internet or any multi-user network.

If there was any real amount of internet address based transactions and tor users I would set up an exit node just to intercept any tor based payments.. I still may do it just to see if I can get any because it's just another way to make a few more bitcoins per day.

I guess what I'm trying to say that it is the equivalent of leaving a pile of cash in your driveway with a rock on top of it to keep it from blowing away in the wind.  Anyone can just go pick it up and so if you're a service provider you would not want to encourage your customers to pay you in that way, because it would just cause problems when the customer says they paid and the service provider says they didn't receive it.  The only reason it's even possible to use on the internet right now is because unlike cash which has perceived value to a lot of people, bitcoins are like a pile of rocks to random internet users, they just walk by.  If there are all these piles of bitcoins in everybody's driveway and people start figuring out that they're valuable, you can bet they'll start disappearing, so it's best not to put them there in the first place.

Laszlo

[satoshi]

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.

[theymos]

How about $ ? It's distinctive, allowed in URLs, and related to money. You could also surround the authentication address in parentheses to emphasize that coins should not be sent to that address directly.

I really like that authentication method.

[Gavin Andresen]

Seems like $ would be inviting confusion, since it's followed by numbers that can look kind-of like a dollar amount:
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3$64.20.45.38

means send $64.20 to my bitcoin address ?

Hyphen or underscore would be less confusing, but I think period would work really nicely:

19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.64.20.45.38
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com

The advantage of that last one is it is a valid URL;  if a user pasted that into Firefox's URL bar or searched for it in Google the website owner could display a helpful web page explaining how to pay.

[laszlo]

Maybe you just use a regular old URL or URN.. Kind of like namespaces in XML.

URN:
urn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78

URL (not for using with a web browser, but it's unique):
http://bitcoin.org/12.34.56.78/19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3

[theymos]

19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com

That's ambiguous. How do we know whether to send coins securely to skypaint.com or insecurely to the IP address that the entire thing resolves to?

Having an informational page at the subdomain would be pretty awesome, though. Maybe it's worth implementing around the ambiguity.

[SirArthur]

The idea of send by DCC is to simplify.

It's not like put 1000 USD over a rock, the attacks are "theoretically easy" but on practical not, unless your ISP attacks you... but if it does so, why not attack your bank account instead? Except maybe for cable access where your neighbor can sniff you.

This bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78 is about as practical as nothing. What would be the simplification-add of such? Try to say to someone over the phone your BC address on such manner.

Let's do one thing, right: PUT TOR ASIDE. One thing is using BC for anonymous payments / OTHER is to make non-anonymous payments.
If you're up to do anonymous payments, that's already sorted: Use BC address and that's it.

It's then a matter of choices, if for security reasons you feel more confortable with it disabled, do it like: Disabled by default / Enable if you want and know what you're doing.

Someone could hijack my site and show another BC address
-Someone could hijack your site and show another PayPal email also. Defacings aren't however easy to do, you don't see sites defaced everyday.

Someone could hijack DNS to resolve to something else
-Someone could hijack your bank's login and make you pass over your password to it... again DNS hijack/spoof isn't also that easy to do. Theoretically (again) it is, but that would be if you were using some bogus Nameserver. If you use your ISP defaults it would be rather complicated. And if someone invaded your PC to make it change DNS's, then that same one would open your BC Client and send all your BC's to his address.

So, in the end, my proposal is:

Split the "project idea" in two different (way different) branches:

1 - Anonymous payments - Using BC Address exclusivelly
2 - Non-anonymous (regular) payments - Using BC Addresses OR DCC.

It makes no sense at all to use Tor arguments over branch 2.

[laszlo]

Bank sites and such use end to end encryption which makes intercepting more difficult and there is usually two way authentication.  The website authenticates itself to you by showing you your personally selected image/phrase, thus you recognize that this is the site you wanted to visit, and then you authenticate to the website so they recognize you as the customer you claim to be.  It's not perfect but it's like putting a pad lock on a box full of money to keep honest people honest.  Sometimes they use a bigger/thicker pad lock so the effort/gain ratio makes it not really worth trying to break it.

I agree with you in a way about security, if it's too inconvenient then it's not very useful... though encryption and authentication are generally good enough to deter trivial things and they provide some reassurance.

It is certainly convenient to be able to send to a paypal email address, but even there you get two way authentication.  PayPal will display the name of the person you're sending to, before you commit to how much you're sending.  PayPal is very popular and is riddled with fraud.. if Bitcoin was accepted on Ebay and the IP address based sending was used as it is today, it would never get there because people would just intercept it along the way, TOR or not.

If you've used ssh you know that uses two way authentication as well - you verify the server's key visually before you present your own authentication credentials.  This technique is problematic in a way because if it's the first time you're connecting you don't know what it should be.. you have to call up the person operating the server and ask them to read you the key.  I think the idea of putting it into the URL or other address notation is that you declare what you expect it to be and the local client will tell you if the peer presents something different.  I suppose you could go the ssh route, just let someone accept whatever is presented.. though right now the key is dynamically generated, it could be changed so that it would present some key that changes once a day or something.. then you could show it on the web site that's expecting the payment, but then why wouldn't you just show the bitcoin address itself and send that way.

I guess I don't really understand your point with simplification.. if you have to copy/paste an address already, what does it matter if it's an internet address, a DNS address or a bitcoin address?

[SirArthur]

Put things this way; if you manage (on a more or less distant future, don't know) to run sort of a shop on surface web* with BC, you may want:

» Your customers to be identifiable - to know who is paying what and handle refunds
» Your customers to leave notes along with the payment.
» Your customers to have a friendly address to pay to (not an IP, not an unreadable hash) - unless you run thenerdsshop.com there is.
» Your customers to not be nagged.

For this would be obviously interesting a TLS/SSL feature. Imagine this operation:

Client -> send BC 50 to bcpay.mysite.com
bcpay.mysite.com -> send a certificate with the store's data, client's get a popup with this server's information to confirm

eg:
You're about to make a payment to the following Bitcoin client:

SITE NAME: mystore.com
COMMON NAME: Payments Gateway
CA VERIFIED BY: BitcoinSSL

Client -> Confirm ? payment is sent: payment is cancelled.


* Tor users: Let's call it a surface web shop shipping goods to your house, so you wouldn't go there anyway. What would be the point of hide your IP while give your home address?

[lachesis]

I don't see why these two ideas are mutually exclusive, although I'd assume implementing SSL/TLS is not trivial. We do already link to the OpenSSL library, so I don't know.

I personally would prefer a urn scheme to handle a bitcoin address.

urn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78

That would be perfect, although I would prefer to use the hostname on the right side.

Of course, I'm the kind of guy who might shop at thenerdsshop.com

For grandma, the entire bitcoin concept is pretty confusing at the moment. Even neglecting all the technical details, the UI still shows a huge string of numbers and letters (your receiving address) and best practices currently require you to deal with that every time you give someone your address.

Another option is to use something like what OpenID uses: hidden tags on the store's (hopefully SSL) site. Then you could just enter a site's URL as the receiving address. It would hit that site, search for something like

Code:

<link rel="bitcoin.address" href="19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3">
<link rel="bitcoin.server" href="12.34.56.78">

Or some other form and try to send securely to that.

[satoshi]

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.

[SirArthur]

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.

It could be used the emule style and register a protocol handle for bitcoin client. So the shop could create link as such:

bitcoin://address-to-pay-to|amount|order hash or id|some other fields

In the end it would resume to such:

<a href="bitcoin://mybitcoin.com|20|aAAee3322AA67|CustomerId=20><img src="paywithbitcoins.jpg" border="0" title="Pay now" /></a>