This is part two in my series about Bitcoin’s Four Hurdles. I have previously addressed usability. Today, I will take a look at transactions. More specifically, transaction volume and the lack of it.

People are discussing whether Bitcoin is a transaction system, a cash equivalent, a store of value, or something else. I believe most people are using it as a store of value right now — an instrument of speculation in anticipation that its full potential will materialize. I have not seen a system with such a potential in a very, very long time. But it still has some way to go to get there.

BITCOIN’S FOUR HURDLES

This is an article in a series on what Falkvinge identifies as Bitcoin’s four hurdles, which will be followed by a series on Bitcoin’s four drivers. This is the second article on transactions. The others are usability, escrow, and exchanges. This is an article in a series on what Falkvinge identifies as Bitcoin’s four hurdles, which will be followed by a series on Bitcoin’s four drivers. This is the second article on. The others are, and

The reason people are not using it as something else than a store of value, I argue, is its lack of usability. There is a strong economic pressure to get the intra-bitcoin transaction volume going. And this, in itself, is the second hurdle that Bitcoin must clear.

Some people have argued that people won’t pay in Bitcoin for as long as it is deflating at this rate. That argument makes no economic sense at all. If I were able to use my disposable income (read “geek toy budget”) using Bitcoin, I would do so immediately. When my paycheck arrived on the last of every month, I would convert my disposable part to Bitcoin, and use it to buy stuff over the course of the month. When I pay for something in the middle of the month, that means I have got two weeks of Bitcoin appreciation-deflation in my back when buying the geek toys. That means more toys for me! Immediate win. The merchant gets the same deflation benefits until change-in and some other, more important benefits, which I’ll be returning to.

Despite the strong business case, this is impossibly hard to pull off today. Therefore, I’ll be ending with some technical proposals.

Somewhat sarcastically, I made this slide as part of a presentation when I wrote this series:

The point is quite clear. There is no Bitcoin economy. It is just used as an instrument of investment, and that is not a sustainable situation.

Then, yesterday, something interesting happened, and I needed to rewrite parts of this article. This image was taken yesterday in Sunnyvale, Silicon Valley, California:

It is quite interesting that the pace of events is so high, that things happen before I get a chance to describe why they will. This development is predicted in the blog post that is scheduled for June 16, which is part three of Bitcoin’s four drivers, but it has already happened. Memory Dealers really nail it:

It’s like cash — it’s free to use and nobody will charge any transaction fees.

Here’s the business case for merchants. Right here. The credit card companies skim about 5% off of every purchase. As do banks handling cash. Every purchase. That’s money that would double the profit margin in a typical business if you could get rid of it. That’s a compelling reason to switch to another payment transaction system, even if you’re basing everything in your business on your local legal tender.

So let’s consider how we can build our bridges from here into the future. As all prices are listed in the legal tender currency, let’s assume that won’t change for the time being. Let’s instead identify the front bowling pin for transaction volume as using Bitcoin as a payment system for the legal tender currency; a payment system with some strong economic side benefits for both buyer and seller, as described. This will be a future driver towards moving more of the financial ecosystem to Bitcoin later on.

I need to be able to pay for a €10 T-shirt with “bitcoin equivalent” just like I can pay for it with “plastic equivalent”.

So what’s lacking here, the way I see it, are some very very simple server-side and client-side components. I need to be able to pay for my new toy with one single click, and the merchant needs to be able to quickly generate a Bitcoin amount server-side (based on the current exchange rate) to pay the item normally listed in the local legal tender, just like the merchant presents a pay-with-Visa form today.

And it needs to be simple and easy.

Technical proposal outline — server side

Assuming a .Net site, this is the amount of code and the level of abstraction that is needed for the transaction volume to take off:

using Bitcoin;

void Application_Start(...) { ... Bitcoin.Connect(); Bitcoin.TransactionReceived += new BitcoinEventHandler (BitcoinReceived); ... }

private string BitcoinPaymentLiteral(ShoppingCart cart) { // This literal is added to the "Pay Now" page // in the shopping cart view. // Generate address and tie it to this cart BitcoinAddress newAddress = Bitcoin.CreateAddress (cart.Amount, "EUR", cart); // Create the literal string literal = String.Format ( "Click <a href=\"{0}\">here</a> to pay €{1:N2} " + "using ฿{2:N2}", newAddress.PaymentUrl, cart.Amount, newAddress.ExpectedAmountBtc); return literal; }

void BitcoinReceived (object sender, BitcoinEventArgs eventArgs) { // This event is fired when we receive funds in BTC. // It is bound in Application_Start. BitcoinAddress address = eventArgs.Address; ShoppingCart cart = (ShoppingCart) address.Cookie; cart.ProcessReceivedPayment(); }

void Application_End(...) { ... Bitcoin.Disconnect(); Bitcoin.TransactionReceived -= BitcoinReceived; ... }

That’s it for the server side. But noticing that BitcoinAddress.PaymentUrl method, we need something client-side as well. So…

Technical proposal outline — client side

This is a simple proposal that can be implemented in anything from a bitcoin client to a Firefox/Chrome plugin:

When somebody clicks on a link in the bitcoin:amount/address format, use the domain of the page clicked and fetch the square-aspect image at /bitcoinlogo.png, and use it to ask for a confirmation in a dialog: “[image] this shop requests that you pay {amount}. Yes or No?”. If yes, transfer the funds to address.

The address is straightforward. The amount should be human readable, and therefore I suggest the following format for amount:

{amount}[k|m|u]

In a short while, we might see things priced at 0.00141 bitcoin. But typing it in like that by hand — which is certainly going to happen on many webpages in a payment link (think “donate here”) — is a major source of error in getting the decimals wrong, even on proofreading. Therefore, I suggest having prefixes in from the start.

The amount 0.00141 could have been better written as 1.41m (1.41 millibitcoin), or 1410u for those who prefer (1,410 microbitcoin). It makes it much more readable. Readability is strongly preferable. (The k prefix works similarly for kilo and will probably only be used to buy mansions and luxury sports cars. I do not foresee a need for a mega prefix.)