Monthly Archives: May 2014

Uncategorized

Bitcoin 2014 Roundup

Well I attended Bitcoin 2014 in Amsterdam and it was a blast. Met lots of people who I’ve been emailing/skyping with over the last six months so that’s always fun.  The conference had a few keynote talks for all and all the rest was broken out into four parallel tracks, always annoying as one wants to attend more than physically possible. There’s no good solution to this classic conference issue, but I’m still annoyed that I missed a few sessions I wanted to attend.

There was a robust collection of exhibitors (approx 40ish) on the show floor and that was fairly impressive for such a young conference. Each session in the tracks had at least 100 or more like 150 attendees. Although I have no other Bitcoin conferences to compare it to, this conference seemed to consist of about 70 percent business oriented fairly mature businesses with the rest being very small startup and random stuff, like bitcoin t-shirts and trinkets.

One of the highlights was Satoshi Nakamoto’s (oops I mean Gavin Andresen’s) state of Bitcoin address. Gavin’s presentation was calm as usual, one of the reasons he’s so good at his job. He noted that his and other core developers tendency is to be very conservative with changes to the core code. Clearly a good choice, since as Bitcoin becomes more mainstream, a LOT of money is reseting on the core code. That being said they are open to the experiments of altcoins in general and when the community is ready core code does get changed. Gavin has been able to turn over the role of chief maintainer to Wladimir van der Laan another core developer and as Gavin expressed, he is now able to start taking off the many hats he was given at the start of the project.

The main keynote talk was by Dr. Patrick Byrne the CEO of Overstock.com.  He presented a long incoherent history of philosophy and currency that lasted over an hour and never really tied it all up to Bitcoin.  Amusingly in a group of 4 people I was just talking with after the talk 3 out of 4 agreed with me but one loved the talk, so who knows.

The various panels and sessions that were part of the parallel tracks covered every topic imaginable. Some were good, some not so much. But it was great to listen to so many points of view. Clearly however the focus of the conference was business, how can we make money off bitcoin, and why is my new whiz-bang bitcoin idea the next great thing.

I also attended the Annual Bitcoin Foundation Member Meeting which was the usual kind of largish meeting. It was mostly “mother-hood and apple pie” run by Jon Matonis the executive director of the foundation and Peter Vessenes. He introduced the new board members Mssrs. Lee and Pierce who both said hello and how glad there were to be there. The silly Pierce controversy was brought up and address IMHO by Peter Vessenes as “a waste of time”. I couldn’t agree more.

Of interest was the finances of the foundation. It apparently began life with an “endowment” of a large chuck of bitcoins. Which is now worth approximately $4.6million. However the burn rate is now approximately $150K/month as there are now ten employees. IMHO and alluded to by Matonis this is fairly non-sustainable. Approximately 70% of the income comes from industry members and 25% from individual members with the rest from donations. This is typical of other foundations I’m familiar with.  Clearly some other type of fundraising and raising of dues will be needed as the foundation covers the running deficit by eating into the endowment, not something you want to do for too long. That being said I do think the foundation is performing a vitally critical role in the bitcoin ecosystem by supporting the development of the core code. One thing different about this foundation unlike the W3C (for example), is that the foundation itself is key to the development of software. The software requires care and feeding and the foundation is the backbone of the Bitcoin software. Satoshi should be a happy camper.

Twitt
bitcoin, Getting Technical

Bitcoin Payment Protocol Explained

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 user names, 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 non 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:

1.Sandy says:  Hey Sharon, how’s it going?

2. Sharon says: Hi Sandy, fine fine, and you?

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

1. Sandy says: “Hey Judy, how’s it going?”

2. Judy says: “Hi Sandy, did you get me that status report yet?”

3. Sandy says: “Yes, I sent it yesterday, but let me check, damn email is acting up”

4. Judy says: “I need it by close of business today.”

5. 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:

Protocol_Sequence

 

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 it’s 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 point of the protocol as stated in the BIP070 abstract, is to make for a better and more secure customer experience. As more wallets and merchants provide more compete support for the payment protocol we will all benefit.

 

 

Twitt