A Bad Argument for High Bitcoin Fees

I just came across Charlie Lee's post about Bitcoin costs. I don't mean to pick on Charlie, whom I've met and whose work on LiteCoin I respect, but he very crisply makes a case for high transaction fees, one that I have often seen repeated elsewhere, and one that happens to be flawed.

The central argument is captured in this quote:

Let’s say there are 5000 miners/nodes, and the marginal cost to process a transaction for a miner (i.e. verify it, add it a block, and store it) is $0.0001. The total cost on the whole network is roughly 5000 * $0.0001, or $0.50. The average transaction fees needs to be $0.50 in order for this network to be sustainable. If the fees were less, less efficient miners will not be able to make more than their cost and will be forced to shut down their miners and quit. This leads to less security and more centralization.

This argument is incorrect.

And not just because it conflates full nodes with miners, who have completely different costs, goals and strategies.

The flaw lies in assuming a closed-world model, where the entire cost of a transaction must necessarily be borne by the person issuing the transaction.

Peer-to-peer system design is all about redistributing the costs to the parties willing to bear them. To put it simply, this argument is flawed because it makes two implicit assumptions: (1) all the participants are rational, self-interested, profit maximizing, and (2) there are no externalities, so the participants benefit only from the transaction fees they collect.

Both of these assumptions are false. The first one is false because many participants to the Bitcoin network are altruists. They choose to subsidize the network because they think the idea is cool or exciting or in line with their political beliefs or helps them identify themselves with the cool crowd. These people willingly contribute resources to the system, and good peer-to-peer system design is all about taking advantage of such freely contributed resources whenever possible.

If you have any doubts about this, just take a look at bittorrent. There is absolutely no incentive to seed files, yet people freely contribute bandwidth. In fact, people even seed files that violate copyright, where the expected financial outcome is negative. A model that cannot accommodate this is broken.

The second assumption is false because there are quite a few externalities not accounted for in the cost model above. For instance, I might want to run a full node, not as a profit-center to profit off of other people's transactions, but because I want to receive occasional payments myself. The cost of ferrying other people's transactions would be folded into the widget sales I would be performing over the network. And once again, good distributed system design is all about taking advantage of such mutually beneficial exchanges.

If you have any doubts about that, just take a look at email (SMTP). There is absolutely no incentive for me to run an SMTP server or a mailing list server, yet I do, because I want to participate in the network myself and gain some hard to characterize utility out of the system. And if you still have doubts, then recall that Bitcoin processed tens of thousands of non-fee-bearing transactions to date, a fact that cannot be explained by this model.

I think this failure is essentially a failure of what I call the "hypermonetization worldview." This view sees every single interaction as a closed economic exchange, modeled in isolation, and attempts to prax out some kind of implication from this isolated model to the real world. And that's why it goes off the rails.

There are lots of good arguments to prefer small blocks over large ones (and vice versa), but this is not one of them.

Related My colleagues Lorenzo Alvisi, Mike Dahlin and their students explored the topic of altruists and rational participants in this interesting paper.

Share on Twitter Share on Twitter

Share on Facebook Share on Facebook

Share on Linkedin Share on Linkedin

Share on Reddit Share on Reddit

Share on E-Mail Share on E-Mail

Please enable JavaScript to view the comments powered by Disqus.

Disqus