What do you do with bitcoin? Why, you spend it of course! Or more precisely you pay for something or some service using it. The specific process to pay using bitcoin is called the Bitcoin Payment Protocol and it is codified in a document called BIP70. A BIP is a Bitcoin Improvement Proposal and is one of the mechanisms used by the Bitcoin “core developers” to improve Bitcoin. There are all sorts of BIPS on lots of great topics but let’s not get diverted. Go to: https://github.com/bitcoin/bips/ and check them out yourself.
Now back to BIP70 the payment protocol. The description is at: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki and is the basis for the technical content of this article. The abstract of the payment protocol states:
This BIP describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process.
Note that a man-in-the-middle (sometimes abbreviated MITM) attack is when a customer connects to a merchant, and it turns out that the customer is not really talking to the merchant. Rather the customer is talking to a man sitting in between (in the middle) the customer and the merchant. This “man” can see all of the traffic going between the customer and the vendor and is thus able to get the usernames, passwords and credit card info and all that sort of personal stuff, by imitating the vendor. With a good imitation the customer will likely be none the wiser. MITM attacks are insidious and technologies (such as the BIP70 payment protocol) to prevent them are important.
Let’s break down the concept of a payment protocol. First, a “payment” is the transfer of value from one individual to another. Second, a “protocol” is a specific process or sequence of messages that must take place in a particular order. As part of the process certain “conditions” might need to be validated for the process to run to successful completion. Sometimes a condition is not met and the process aborts or returns an error message, but the protocol itself should be able to handle all of these conditions, making it a “robust” protocol.
A payment protocol is a sequence of messages between the customer and the vendor, in a particular order, with an expected set of responses, or acknowledgements that are part of the messages. Let’s look at a particular set of messages that I will call the “passing in the hallway protocol” (PITHP). If you work in a building and happen to pass by colleagues, it might go something like:
- Sandy says: Hey Sharon, how’s it going?
- Sharon says: Hi Sandy, fine fine, and you?
- Sandy says: “same old, same old”
and we’re done, exciting ayee?
That simple “passing in the hallway protocol” was a sequence of messages passed from one person to another in an expected order. Of course things might not go as expected in which case additional condition handling messages might be needed.
- Sandy says: “Hey Judy, how’s it going?”
- Judy says: “Hi Sandy, did you get me that status report yet?”
- Sandy says: “Yes, I sent it yesterday, but let me check, darn email is acting up”
- Judy says: “I need it by close of business today.”
- Sandy says: “No prob. I’ll resend it.”
The code that implements the protocol must deal with all the various types of exceptions and conditions that can happen. ALL of them.
There is very informative illustration in BIP70:
Note that the customer sends messages to the merchant, however two other entities come into play. First the bitcoin wallet application itself, and the bitcoin network. You read the illustration from top to bottom which denotes the specific sequence of messages. The diagram however does not specify all of the possible options that the code must handle. For example, if the merchant server does not respond with a “PaymentRequest” message then the customer must do something such as repeat the “pay now?” message or abort the whole transaction.
Let’s walk through the diagram in plain english:
The customer clicks on a “pay now” button which sends a message to the merchant server. The merchant server requests a payment from the wallet application (belonging to the customer). The wallet application asks the customer, “are you sure you want to authorize this payment?” To which the customer clicks, “OK”, sending a message to the wallet application. The wallet sends the payment to the merchant and possibly at the same time it initiates a transaction to the Bitcoin network. The Bitcoin network does its transaction thing, causing the merchant to receive bitcoin. The merchant server acknowledges the payment sending a message to the wallet, and finally (optionally) the wallet sends a message back to the customer.
A very thorough, yet quite understandable, explanation of the details of the payment protocol was authored by Mike Hearn and is available at: https://bitcointalk.org/index.php?topic=300809.0 There are a LOT more details to the payment protocol I would simply suggest keeping in mind that the point of the protocol as stated in the BIP70 abstract, is to make for a better and more secure customer experience. As more wallets and merchants provide more complete support for the payment protocol, we will all benefit.
