The Economic Limits of Bitcoin and Anonymous, Decentralized Trust on the Blockchain

Budish, Eric B., The Economic Limits of Bitcoin and Anonymous, Decentralized Trust on the Blockchain (June 27, 2022). University of Chicago, Becker Friedman Institute for Economics Working Paper No. 83, 2022. SSRN: http://dx.doi.org/10.2139/ssrn.4148014

Abstract: Satoshi Nakamoto invented a new form of trust. This paper presents a three equation argument that Nakamoto’s new form of trust, while undeniably ingenious, is extremely expensive: the recurring, 'flow' payments to the anonymous, decentralized compute power that maintains the trust must be large relative to the one-off, 'stock' benefits of attacking the trust. This result also implies that the cost of securing the trust grows linearly with the potential value of attack — e.g., securing against a $1 billion attack is 1000 times more expensive than securing against a $1 million attack. A way out of this flow-stock argument is if both (i) the compute power used to maintain the trust is non-repurposable, and (ii) a successful attack would cause the economic value of the trust to collapse. However, vulnerability to economic collapse is itself a serious problem, and the model points to specific collapse scenarios. The analysis thus suggests a 'pick your poison' economic critique of Bitcoin and its novel form of trust: it is either extremely expensive relative to its economic usefulness or vulnerable to sabotage and collapse.

A Discussion of Responses to this Paper’s Argument

This paper first circulated in shorter form in June 2018. I received a lot of comments and counterarguments in response to the paper’s main line of argument. I have tried to handle the central line of counter-argument throughout the main text of this updated draft. This is the point made by Huberman, Leshno and Moallemi (2021) and many practitioners that we should compare Bitcoin’s costs to the costs of market power in traditional finance, which are also high.24 I hope the present draft of the text makes more clear the conditional nature of the paper’s argument: if Bitcoin becomes more economically useful, then it will have to get even more expensive, linearly, or it will be vulnerable to attack. I hope as well that the more explicit computational simulations, for varying levels of Vattack all the way up to $100 billion, make clear that the way Bitcoin’s security cost model scales is importantly different from how costs scale for traditional finance protected by rule-of-law. In this appendix I discuss several of the other most common comments and counter-arguments I have received about this paper since it was first circulated.

A.1 Community

As noted above in Section 5, a majority attack on Bitcoin, or any other major cryptocurrency, would be widely noticed. A line of argument I heard frequently in response to the June 2018 draft is that the Bitcoin community would organize a response to the attack. For example, the community could organize a “hard fork” off of the state of the blockchain just prior to the attack, which would include all transactions perceived to be valid, void any perceived-as-invalid transactions, possibly confiscate or void the attacker’s other Bitcoin holdings if these are traceable, and possibly change the hash function or find some other way to ignore or circumvent the attacker’s majority of compute power.25 The community response argument seems valid as an argument that attacks might be more expensive or difficult to execute than is modeled here, but it raises two important issues. 24See Philippon (2015) and Greenwood and Scharfstein (2013) on high costs of traditional finance, and see Cochrane (2013) for a counterpoint. 25The phrase “hard fork” means that in addition to coordinating on a particular fork of a blockchain if there are multiple — in this case, the attacker’s chain, which is the longest, and the chain the community is urging be coordinated on in response — the code used by miners is updated as well. This could include hard-coded state information such as the new chain or information about voided Bitcoins held by the attacker, code updates such as a new hash function, etc. First, and most obviously, the argument contradicts the notion of anonymous, decentralized trust. It relies on a specific set of trusted individuals in the Bitcoin community. Second, consider the community response argument from the perspective of a traditional financial institution. In the event of a large-scale attack that involves billions of dollars, the traditional financial institution would, in this telling, be left in the hands of the Bitcoin community. At present, reliance on a tight-knit community of those most invested in Bitcoin (whether financially, intellectually, etc.), may sound reassuring — those with the most to lose would rally together to save it. But now imagine the hypothetical future in which Bitcoin becomes a more integral part of the global financial system, and imagine there is a fight over whether an entity like a Goldman Sachs is entitled to billions of dollars worth of Bitcoin that it believes was stolen — but the longest chain says otherwise. Will the “vampire squid” be made whole by the “Bitcoin community?” Quite possibly, but one can hopefully see the potential weakness of relying on an amorphous community as a source of trust for global finance.

A.2 Rule of Law

A related line of argument is that, in the event of a large-scale attack specifically on a financial institution such as a bank or exchange, rule of law would step in. For example, the financial institutions depicted as the victims of a double-spend in Figure 2, once they realize they no longer have the Bitcoins paid to them because of the attack, would obtain help from rule-of-law tracing down the attacker and recovering the stolen funds. This response, too, seems internally valid while contradicting the idea of anonymous, decentralized trust. It also seems particularly guilty of wanting to “have your cake and eat it too.” In this view, cryptocurrencies are mostly based on anonymous, decentralized trust — hence evading most forms of scrutiny by regulators and law enforcement — but, if there is a large attack, then rule-of-law will come to the rescue.

A.3 Counterattacks

Moroz et al. (2020) extend the analysis in Budish (2018) to enable the victim of a double-spending attack to attack back. They consider a game in which there is an Attacker and a Defender. If the Attacker double spends against the Defender for v dollars, the Defender can then retaliate, themselves organizing a 51% or more majority, to attack back so that the original honest chain becomes the longest chain again. This allows the Defender to recover their property. For example, suppose the escrow period is 6, denote the initial double-spend transaction as taking place in block 1, and suppose the attacker chain replaces the honest chain as soon as the escrow period elapses, as in Figure 2. Notationally, suppose the honest chain consists of blocks {1, 2, ..., 7} at the time the honest chain is replaced, and the attacker chain that replaces it is {1’, 2’, ..., 7’, 8’}. If the Defender can quickly organize a majority of their own, then they can build off of the {1, 2, ..., 7} chain, and eventually surpass the attacker chain, recovering their property. For example, maybe the honest chain reaches block 10 before the Attacker chain reaches block 10’, so then {1, 2, ..., 10} is the new longest chain and the Defender has their property back from the correct transaction in block 1. This argument is game theoretically valid, and indeed there are theoretical subtleties to the argument that the reader can appreciate for themselves in the paper. That said, it relies on every large-scale participant in the Bitcoin system being able and willing to conduct a 51% attack on a moment’s notice. This is kind of like requiring every major financial institution to have not just security guards, but access to a standing army.

A.4 Modification to Nakamoto I: Increase Throughput

Bitcoin processes about 2000 transactions per block, which is about 288,000 per day or 105 million per year. In contrast, Visa processes about 165 billion transactions per year (Visa, 2021). The reader will notice that the logic in equations (1)-(3) does not depend directly on the number of transactions in a block. If the number of transactions in a Bitcoin block were to increase by 1000x (to roughly Visa’s level), then the required pblock to keep Bitcoin secure against a given scale of attack Vattack, per equation (3) would not change. Thus, the required cost per transaction to keep Bitcoin secure against a given scale of attack would decline by a factor of 1000. In this scenario of a 1000x throughput increase, Bitcoin’s security costs per transaction are still large, but less astonishingly so. In the base case, to secure Bitcoin against a $1 billion attack would require costs per transaction of $31 instead of $31,000. To secure against a $100 billion attack would require costs per transaction of $3,100 instead of $3.1 million. A subtlety is that as the number of transactions per block grows, so too might the scope for attack. That is, Vattack might grow as well. Still, this seems a promising response to the logic of this paper. A particularly interesting variation on this idea is the paradigm called “Level 2.” In this paradigm, the Bitcoin blockchain (“Level 1”) would be used for relatively large transactions, but smaller transactions would be conducted off-chain, possibly supported with traditional forms of trust, with just occasional netting on the main Bitcoin blockchain. In this paradigm, as well, the large transactions on chain could also have a long escrow period, making attacks more expensive.26 26I thank Neha Narula for several helpful conversations about this approach.

A.5 Modification to Nakamoto II: Tweak Longest-Chain Convention

The discussion above in A.1 expressed skepticism about the “community” response to the logic of this paper. However, what about modifying the longest-chain convention to try to encode what the community would want to do in the event of an attack. The modification to the longest-chain convention could take advantage of two specific features of double-spending attacks: 1. The Attacker has to sign transactions both to the victim of the double-spending attack — call this the Bank — and to another account they control — call this the Cousin account. The fact that there are multiple-signed transactions for the same funds is an initial proof that something suspicious has happened. 2. The Attacker has to make the signed transaction to the Bank public significantly before — in “real-world clock time” — the signed transaction to their Cousin account. The difficulty with just using facts #1 and #2 to void the transaction to the Cousin is alluded to with the phrase “real-world clock time.” Part of what the Nakamoto (2008) blockchain innovation accomplishes is a sequencing of data that does not rely on an external, trusted, time-stamping device. Relatedly, the difficulty with just using fact #1 and having the policy “if there are multiple correctly signed transactions sending the same funds, destroy the funds” is that the victim of the double-spending attack, the Bank, will by now have sent real-world financial assets to the Attacker — and this transaction, in the real world (off the blockchain), cannot be voided no matter how we modify the blockchain protocol. A different way to put the concern is that such a policy would allow any party that sends funds on the blockchain in exchange for goods or financial assets off the blockchain, to then void the counterparty’s received funds after the fact. This seems a recipe for sabotage of the traditional financial sector. The open question, then, is whether the protocol can be modified so that in the event of fact #1, multiple signed transactions, there is some way to appeal to fact #2, grounded in the sequencing of events in real-world clock time, not adjudicated by the longest-chain convention’s determination of the sequence of events.

One pursuit along these lines is Leshno, Pass and Shi (in preparation).

A.6 A Different Consensus Protocol: Proof-of-Stake

Proof-of-stake is widely discussed as an alternative consensus protocol to Nakamoto’s (2008) proofof-work. In this paradigm, rather than earning the probabilistic right to validate blocks from performing computational work, one earns the probabilistic right to validate blocks from locking up stake in the cryptocurrency. The usual motivation for proof-of-stake relative to proof-of-work — the deadweight loss and environmental harm associated with proof-of-work mining, which as noted currently utilizes about 0.3-0.8% of global electricity consumption — is in fact completely orthogonal to the concerns in this paper. In its simplest form, proof-of-stake is vunerable to exactly the same critique (1)-(3) as proof-of-work. Just conceptualize c as the rental cost of stake (i.e., the opportunity cost of locking up one unit of the cryptocurrency), as opposed to the rental cost of capital plus variable electricity cost of running the capital. The amount of stake that will be locked up for validation will depend on the compensation to stakers, as in equation (1). This amount of stake in turn determines the level of security against majority attack, as in equation (2). Thus, equation (3) obtains, with the per-block compensation to stakers needing to be large relative to the value of a majority attack. See Gans and Gandal (2019). However, while in its simplest form proof-of-stake is vulnerable to the same economic limits as proof-of-work, the use of stakes rather than computational work may open new possibilities for establishing trust and thwarting attacks. The advantage is that stakes, unlike computational work, have memory. 27 It is possible, for instance, to grant more trust to stakes that have been locked up for a long period of time, and that have never behaved suspiciously (see Appendix A.5 just above), than to stakes that have only recently been locked up. Stakes can also be algorithmically confiscated by the protocol, whereas ASIC machines exist in the “real world”, outside of the grasp of the protocol. Thus, it seems possible that proof-of-stake could make majority attack significantly more expensive (relative to the level of economic activity) than it is under proof-of-work. That said, proof-of-stake has other potential weaknesses relative to proof-of-work, such as the “nothing-atstake” and “grinding” problems, and its game-theoretic foundations are less well understood. See Halaburda et al. (forthcoming), Section 3.6 for a detailed discussion, and Saleh (2021) for an early game-theoretic analysis. Notably, Ethereum, the second-largest cryptocurrency after Bitcoin, has been considering a move to proof-of-stake for some time. See Buterin (2014, 2016, 2020); Buterin and Griffith (2019). Much of the other research on proof-of-stake also seems to be happening outside of the traditional academic process. It will be interesting to see if a proof-of-stake protocol proves to be a convincing response to the logic of this paper.