The economics of Bitcoin as payment protocol

As excitement over Bitcoin as a new form of currency has met with strong pushback from the economics world, the smarter commentators have shifted focus to cryptocurrency as a new way to move money around on the Internet. But how would that really work? The first thing you hear in these discussions is that Bitcoin transactions bypass traditional credit card fees. My first question was why? Specifically, isn’t at least part of the point of those fees to cover necessary services like fraud protection that will need to be implemented with Bitcoin as well? I asked Bitcoin entrepreneur Jeremy Allaire about this in an interview for HBR, and he gave a plausible answer. Basically, with Bitcoin no single entity bears the cost of clearing the transaction or maintaining the network to do so. Companies like Allaire’s Circle still need to provide anti-theft protection, and so it’s far from certain that the economics for Bitcoin will be superior, but for the purposes of this piece I’ll grant his assumption. As we’ll see, things only get more complicated from there.

So my starting point is the assumption that a Bitcoin transaction is cheaper than a (non-cash) dollar transaction. Could you build a payment app that just uses Bitcoin to exchange dollars, similar to how Business Insider’s Joe Weisenthal describes, and if so would it be cheaper? Here’s Weisenthal:

Bitcoin is fundamentally a way to make transactions in a fiat currency. If you want to sell me something for $850, I could pay you in cash, credit card, via PayPal, bank wire, or possibly Bitcoin. How many Bitcoins this transaction requires (currently it would be right around one) is a function of fluctuating Bitcoin prices, but essentially we’re carrying out a dollar-priced transaction and using the Bitcoin as the payment system.

You could build such an app, but you’d quickly run up against another kind of fee. If I want to buy $10 worth of something from a merchant with dollars, but using Bitcoin, the app needs to make two currency conversions. First, you need to take my $10 and convert it into Bitcoin, for which you’ll be charged a fee. And then you need to take the x Bitcoin that is transferred to the merchant and you need to convert it back into dollars. So you effectively have two transactions here, each with a fee that is roughly comparable to a credit card transaction. So you’re not really saving any money.

You might think that a way around this would be to use batching — as an example think of the way people put money onto Starbucks gift cards. I put on $50 which requires a one-time conversion fee to turn into Bitcoin, and then I make several purchases with Bitcoin over time. This does save you some money, since the Bitcoin transactions are cheaper than credit card transactions (per our assumption) and because converting all $50 into Bitcoin at once saves some money. (This is because interchange fees and currency fees both involve a mix of flat and percentage-based fees. So if I only do one fee-based transaction in the beginning and then do a bunch of cheap/free Bitcoin transactions, I’m saving a bit relative to the flat fee that would be assessed doing each transaction in dollars.)

But there’s a problem here, too. Why not just scrap Bitcoin, and batch payments in dollars? The savings in the above case are really coming from lumping together transactions to minimize flat fees — but we don’t need Bitcoin to do that. Indeed, the mobile payment startup LevelUp does this, best I can tell, on a monthly basis. (An email from the company says it’s to “to help local businesses save on card processing fees.”) Bitcoin does have the advantage of verifying at each transaction that the buyer actually has the money, so you don’t get to the end of a batch period and find out someone can’t pay. But the fact that LevelUp is using this approach suggests that the advantage might be quite small.

So we’re really back to square one, or at least close. Unless currency conversion fees are lower than interchange fees, I have trouble seeing how Bitcoin amounts to a cheaper way to move dollars around the Internet. In other words, if Bitcoin doesn’t work as a currency, I struggle to see how it will work as a payment protocol. Of course, we are early days and all that. Mostly, I’d really like to read a detailed account of how Bitcoin-as-payment-protocol would work so please point me in the right direction.


In the process of thinking all this through, I came up with an interesting hypothetical. Assume for a minute that the fixed supply of Bitcoin suggests its value will appreciate over time (and put aside volatility for a moment). Imagine you built a digital payment app that used Bitcoin but didn’t bill itself as being about Bitcoin at all.

Here’s how it would work: I put $20 onto the app, which behind the scenes is immediately exchanged for Bitcoin. But rather than telling me I have x Bitcoin to spend, you simply guarantee I can spend $20 dollars. I spend that money over time — say a month — during which the value of Bitcoin appreciates. Because of that, once I’ve spent my $20 there’s still some Bitcoin left over. And because this isn’t a Bitcoin app — I don’t know/care that that’s how you’re processing my payments — you just go ahead and pocket that residual to cover fees and for a profit.

Of course, the company behind the app needs to worry about the loss it would face if the price of Bitcoin goes down over that period. But if you believe there’s a fundamental deflationary bias in Bitcoin, that suggests that to the extent that it is used, its value will appreciate. Moreover, it may be advantageous to have firms rather than individuals taking on the risk around Bitcoin’s price volatility, in both directions. I don’t have to worry (much) since my dollars are guaranteed so long as the app company is solvent.

What really interests me in this scenario is the fact that the deflationary spiral that supposedly occurs when a currency appreciates over time is driven by hoarding. If you know your money will be worth lots more tomorrow, you’re unlikely to spend it. But in this case, I don’t really even know that I’m using Bitcoin so I’m unlikely to hoard it. So demand keeps ticking along. Could such a dynamic help mute the recessionary tendencies of a fixed supply currency?

No doubt there is a reason why this whole thing wouldn’t work — look forward to hearing folks’ thoughts as to why not.

The real danger of Bitcoin

It’s been interesting to see the debate over Bitcoin start with currency, move on to payments, and now there are rumblings that its real use isn’t for either. Rather, cryptocurrency could be a way of marking digital goods as unique, making them in effect rival. Technology Review explains:

Or take digital art. Larry Smith, a partner at the business architecture consultancy The matix and an analyst with long experience in digital advertising and digital finance, asks us to “imagine digital items that can’t be reproduced.” If we attached a coin identifier to a digital image, Smith says, “we could now call that a unique, one-of-a-kind digital entity.” Media on the Internet—where unlimited copying and sharing has become a scourge to rights holders—would suddenly be provably unique, permanently identified, and attached to an unambiguous monetary value.

This would almost certainly be bad news for the Internet. The ability of users to copy digital content has put necessary pressure on rights holders to lower costs, change business models, and innovate. We live under a ludicrous intellectual property regime in which rights holders lobby their way to ever-extending copyright terms. Making it easier for rights holders to enforce copyright online would result in more expensive content and would take all the pressure off both for improved digital distribution models and intellectual property reform. Put simply, the non-rivalry of digital goods is one of the things that has made the Internet such a boon for consumers. If cryptocurrency undoes that, it would be a shame.

How will self-driving cars solve the trolley problem?

Recall the classic utilitarian morality puzzle (via Wikipedia):

There is a runaway trolley barrelling down the railway tracks. Ahead, on the tracks, there are five people tied up and unable to move. The trolley is headed straight for them. You are standing some distance off in the train yard, next to a lever. If you pull this lever, the trolley will switch to a different set of tracks. Unfortunately, you notice that there is one person on the side track. You do not have the ability to operate the lever in a way that would cause the trolley to derail without loss of life (for example, holding the lever in an intermediate position so that the trolley goes between the two sets of tracks, or pulling the lever after the front wheels pass the switch, but before the rear wheels do). You have two options: (1) Do nothing, and the trolley kills the five people on the main track. (2) Pull the lever, diverting the trolley onto the side track where it will kill one person. Which is the correct choice?

How should we program robots to answer this question? Specifically, what about self-driving cars? Should they be programmed to injure or kill their driver in order to save many others? The question is raised at minute three of this short video on robots and ethics. The whole video is worth your time.