Hostnames instead of IP Addresses

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".

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.

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

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.

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

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.

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?

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.