(context post by 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?

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?

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

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:

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

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.