Merchant-friendly payments: less than perfect, but better than before

Bitcoin is due for an overhaul of its payment mechanism to make it more merchant-friendly, but the core dev team is working with an imperfect system, they say.

The basic idea behind the Payment Request initiative is to give Bitcoin a mechanism for sending verified payments directly between people. This doesn’t take transactions away from the blockchain, but it does provide an extra layer of security between merchant and customer. It also makes payments more user-friendly.

In the traditional bitcoin payment system, bitcoins are sent by manually pasting a long, gibberish alphanumeric address into a bitcoin client. Some clients allow for QR codes of addresses to be scanned.

“It’s great technically but it looks like a monkey banging on a keyboard to the average person,” says core developer Jeff Garzik. Aside from being difficult for the average non-techie to understand or use, the gobbledygook address format makes a number of attacks possible. “For example you don't know whether the bitcoin address I gave you is really mine,” he points out.

There is a danger that the address is either inaccurate, or simply fraudulent. I could pretend to be a known legitimate merchant online, or perhaps send a phishing attack asking you for money. If you fell for the scam and paid me, your money would be gone. After all, bitcoin payments are irreversible.

The other problem with existing bitcoin payments is while they are permanently registered in the blockchain, they’re not easy to document when they’re happening. There is no metadata encoded in the payment information itself that says what it’s for. Neither is there any information about a return address for refund purposes. Any refunds have to be arranged separately. And if you want to confirm immediately that your bitcoin payment reached its recipient, then you have to get separate confirmation from them.

All of this may have seemed reasonable in 2009, but things have moved on. We need something more robust now, argues Pieter Wuille, one of Bitcoin’s seven core developers. “In almost all cases, you are already visiting the merchant's website in order to make an order. It's pretty strange that we're now relying on the (slow, unreliable, expensive and unflexible) peer-to-peer network to get his payment to him, while we could just send it to him directly (faster, cheaper, ability to add metadata to the transaction, and most importantly, an instant confirmation from the merchant that they received it).”

The Payment Requests mechanism will attempt to do just that. Instead of having to send payments to a cumbersome bitcoin address, someone wanting to pay for something in bitcoins can simply wait for a request to be emailed by the merchant, or served via a website. The customer’s bitcoin client uses the information contained in the Payment Request to make a payment, making the payment process more secure.

Payment Requests use digital certificates to try and solve the problem, in the same way that websites use them to prove that the sites are owned and operated by the true owners of a business.

In the dark old days of the Internet, it was easy to visit a web site that you thought was owned by a certain company, (www.microsoft.com, say) only to end up on a fraudulent site run by a scammer (perhaps www. m1cros0ft.com). Many people fell vulnerable to phishing attacks thanks to this flaw. So the industry introduced digital certificates. Sites would serve up these certificates, which were obtained from trusted third party companies called certificate authorities. Browsers would look for the certificates, and throw up an error if it didn’t find them.

The core developers want to use the same basic premise for payments. A merchant will send a payment request to the customer, signed with a digital certificate. It can include information such as an expiry date for the payment, merchant-specific data such as an invoice number, a plain text note, and a URL to send payment to. None of this information was available in a standard bitcoin payment before, because there wasn’t a payment request. The customer would simply send bitcoins off into the ether, hoping that they were landing with the right person.

In the new system, the customer will send their payment to the merchant, encoded with extra information, including some of the information in the payment request as a reference, along with a refund address in the event that the merchant needs to send funds back.

It’s all very grown-up, and something that Bitcoin has long needed, which is why it’s been on the drawing board for the last year or two. But the system that it will be built on is far from perfect, admit the core devs.

Certificates are difficult to do well. What happens if a certificate is fraudulent, as happened here, here, and here? What happens if a certificate has been revoked?

“In general, public key trust infrastructure is a very hard problem, and there is no silver bullet for it, unfortunately. The SSL PKI is sort of the worst existing system, after all others,” admits Wuille.

SSL is the colloquial name for X.509, the certificate standard that will be used for the Payment Request mechanism. Experts have long criticized it for its flaws. Dan Kaminsky and Moxie Marlinspike are demigods in the security business. They blew the lid off X.509 security vulnerabilities at the infamous Defcon hacker conference in 2009.

Other problems with X.509 include certificate revocation. Certificates can be revoked for a number of reasons, including certificate holders providing false documents, or doing other specious things online. X.509 uses a system called the Online Certificate Status Protocol (OCSP) to see which certificates have been revoked.

“The consensus among experts is that the certificate revocation system (OCSP) doesn't work,” says lead developer Gavin Andresen. “There just aren't strong enough incentives for the certificate authorities to invest in the infrastructure to support millions of users constantly querying their OCSP servers and asking ‘Is this certificate revoked? No? How about now?’.”

So, at least two of the seven core developers admit that X.509 has cracks in it. Why are they using it? Like it or not, pretty much the entire Internet uses SSL, and in practice, the core devs don’t really have a choice in this. If you’re an online merchant, you probably have an SSL certificate. Even if the core dev team had the capacity to tackle the public key infrastructure problem and build a better mousetrap, they’d have to get people to use it. It’s enough of a struggle getting merchants interested in bitcoin in the first place, without making them register for another certificate all over again.

Nothing in tech is perfect, and as Andresen says, web-based merchants don’t rely on OCSP in practice either. X.509 is still more secure than the bitcoin addresses in use today. Any step forward is better than nothing.

A better payment mechanism would bring significant benefits to Bitcoin. The enhancements to the user experience shouldn’t be underestimated. One day, Andresen would like to see the bitcoin addresses currently used disappear forever. “Hopefully, eventually,” he says. “Bitcoin addresses are not very user-friendly.”

Bitcoin addresses won't be officially deprecated, says core developer Nils Schneider, but they might very well be used less when dealing with merchants, especially given that they currently have to generate separate bitcoin addresses for each transaction.

“As of now, using a different address for each transaction is the preferred way to keep transactions apart. This means creating and storing a private key for each transaction,” he explains. “With payment requests, you may use the same key multiple times and still be able to tell different transactions apart and know which customer sent the money.”

There is a lot of infrastructure already built on standard bitcoin addresses, says Wuille. That’s a lot of inertia to deal with. But he hopes that the superior customer experience will make it worthwhile. “Let's focus on trying to get e-business transactions to use it first, and we'll see about the rest.”

So, when is all of this likely to happen? The core devs aren’t committing to much. They’re shooting for payment requests in Bitcoin v0.9, but it’s not a dead cert, says Wuille. “We make releases whenever necessary. In case there's an important security update, there can be new releases of the 0.8.x series before 0.9,” he says. “The plan is to have payment protocol support in 0.9, but if this turns out to need significant and unexpected delays, perhaps 0.9 can be released without.”

Payment Requests may face its challenges, but it’s good for bitcoin, and it’s a bold move from a notoriously conservative development team. Anything that can make the process of sending the cryptocurrency between parties more securely and effectively will be a good thing.