It is no secret that bitcoin usability has room for improvement. Fortunately, a new feature planned for the bitcoin v0.9 release will significantly increase merchant and customer usability in four key areas: ease of payment, recurring payments, dispute resolution, and immediate-feedback transactions. The key improvement is a new type of payment messages where a merchant can send a signed request (PaymentRequest) specifying the amount to be paid and a description of the transaction. The customer can then send payment to the merchant and receive an acknowledgement (PaymentACK) of the transaction with a message from the merchant. Before discussing the advantages of the implementation, it’s important to understand a few key aspects of the changes.
It is currently common practice is to generate new bitcoin receiving addresses for each customer to ensure funds can be associated with each individual’s account. However, this raises issues for merchant-initiated transactions since the recipient of the request must verify the authenticity of the requester. To solve this problem 0.9 will use X.509 certificates to sign the payment request. X.509 certificates are frequently used to sign website sessions and are issued by a central authority to a specific party. Payment requests can be signed by holders of these certificates to prove the authenticity of the request.
X.509 was chosen over some alternative certificates for two reasons. First, they are simple and fairly easy to manage, exempt from unnecessary features of some of the other existing payment standards. Second, most sites will have already used X.509 certificates for their website, so they will already have them available and experience implementing them.
Once PaymentRequests become popular, users will likely have to filter through many requests, even by the same issuer, to identify a specific transaction. The 0.9 implementation plans to allow a description field, such as “VPN service for March,” to identify the transaction in more detail.
Additionally, people may be paying out of hosted wallets, such as an account on an exchange, that do not provide a reliable address in the event of a refund. If a refund was sent back to the issuing address, it is likely the hosting service will not be able to associate the incoming payment with the intended recipient. The ability to provide a refund address will allow a refund transaction to be sent to a different address than the coins were sent from, alleviating this concern.
There are two concerns with the new implementation. One of the primary appeals of bitcoin for many users is the decentralization of the network. X.509 certificates are issued by central authorities, so trust in their signatures is derived from the issuers’ credibility. While this risk is not likely to be prevalent in transactions, it does increase vulnerability so large transactions would be better off not using this payment method. Additionally, it is difficult to check for revoked certificates. There would likely be false-positive rejections if the Online Certificate Checking Protocol (OCSP) were offline or overwhelmed.
There are many use cases for this new implementation that will significantly improve the usability of bitcoin without requiring the involvement of 3rd party features. Manually entering strings of digits accurate up to eight decimal places leaves room for human error. Using PaymentRequest, merchants can send the exact transaction amount to a customer, to which the customer simply responds with an acknowledgement and knows the correct payment amount was sent without having to copy or enter payment amounts themselves.
Recurring payments in 0.9, although only a request and not a direct charge, will be significantly easier to implement. Subscription services have been hesitant to implement bitcoin as a payment feature because of the lack of ability to bill customers at regular intervals.
There are two methods that could leverage these changes to maintain subscription payments. If a request is sent several days before payment is due, users will be reminded to pay the service and process the transaction manually. Additionally, wallet programs could be developed that automatically pay a request with pre-approved criteria, such as being from a specified merchant and/or below a certain value threshold. Automatic billing could then be implemented with the customer’s consent.
Dispute resolution will also be made far clearer. After the transaction is completed, the customer will now have a signed receipt. It will be trivial to prove payment to a merchant’s using the PaymentRequest, transaction ID, and PaymentACK. In the context of a mediator while using an escrow service, both parties will have clear evidence of how the transaction completed so escrow funds could be released.
Additionally, if a customer sends payments and the merchant does not uphold their end of the transaction, a publicly visible receipt is available for proof. Merchants will find themselves beholden to fulfilling their end of an agreement in order to manage reputation in a world with extensive public communication via forums and social media.
Satoshi Dice and other related services have been blamed with unnecessarily inflating the size of the block chain. These services use small transactions to send messages for merchant communication. Using a message embedded in PaymentACK, sites can notify users of a win or loss without sending an additional transaction as confirmation over the block chain. Winning proceeds will be sent to a refund address, and losses will simply receive the PaymentACK message stating there was a loss. While this will not reduce the block chain overhead as much as the bitcoinj implementation, its benefits will be immediately noticed upon implementation by these services.
The bitcoin community owes thanks to the Core Development Team that is dedicating significant time to improving usability for the entire bitcoin system. As the bitcoin infrastructure continues to become more robust with a larger number of sophisticated exchanges and merchant services, improvements in the usability of the protocol itself will add significant stickiness to the bitcoin network.