Much about the current Bitcoin splitting debate has revolved around the notion of a hard fork splitting of the network being dangerous. So dangerous, in fact, that core developers have constantly stuck to the argument that the community should trust in their (exclusive) council in order to ensure that we don’t engage in anything that may be unsafe for ourselves. Trust them, they know what is good for us. When libertarians and skeptics around the world hear that they are immediately put on alert.
Most recently an exchange between ex-Bitcoin lead maintainer Gavin Andresen with Core contributor Matt Corallo was especially interesting. Besides the run-of-the-mill talking past each other where Matt seems to ignore points that Gavin clearly addressed (regarding n**2 sighash issues, solved by capping txn sizes to 1mb) the core theme (pun intended) repeated again by Matt was that Hard Forks have no community support (by his own judgement) which is clearly shown by the fact that nobody seems to be giving much attention to the HF proposals in his (exclusive core dev curated) proposal list. Not much surprise here, the standard echo-chamber reality distortion field stuff. What was interesting, was that he once again mentioned the need, nay, the necessity of ‘replay protection’ in ANY hard fork proposal. This is very important point in the core dev platform, as it serves a dual purpose. One which on the surface is ostensibly for the public good, the other may be much more shadowy. Let’s examine what replay protection is, and why we really don’t need it.
The basic premise of replay protection was first popularized with the now infamous ETH/ETC splitting. In an article that described the problems when a transaction posted on one chain would be secretly rebroadcast to the other, the author explained the complications with accounting on both chains due to this issue, which was an ‘attack’ against the payee that would result in them ‘paying twice’. Sounds pretty bad right? Of course it does. The language was meant to be evocative. Technical people know that Ethereum isn’t Bitcoin, and the same ‘attack’ would be very different, and arguably not even a threat in the Bitcoin network. For starters, Bitcoin doesn’t hold balances. Each txn output is linked chain of historical events, unique and cannot be simply reapplied to another chain if its histories are not compatible. Secondly, due to the fast block times and fast difficulty re-adjustment schedule of Ethereum, sending the txn on the other chain would often get a confirmation equally as quickly as on the main chain. Additionally ETH client nodes on both sides do not partition themselves from each other on the P2P network level, thereby allowing 2 blockchains to run simultaneously on 1 network, which only exacerbates the issue. None of these vulnerabilities exist in Bitcoin. In Bitcoin, the replay ‘attack’ is arguably not an attack at all. Let’s examine all the scenarios.
Alice and Bob the Carpet Salesman
If we assume that Alice has bitcoins in address A, and she wants to pay Bob the carpet salesman at his address B. Let’s also assume that we are in a situation where there has been a hard fork splitting of Bitcoin, and now there is both BCC and BCU chains. Each and every BTC that existed before the splitting of the chains is useable on both new BCC and BCU chains. But new coins minted in BCC or BCU are not useable on the other and vice-versa. Alice creates a transaction, A->B and sends it to Bob who is selling her a carpet for BCU. If Alice’s bitcoins in A were last paid to her before the fork, then this transaction would be equally valid on the BCC chain, and thus, after receiving his payment, Bob, could, (with some specialty know-how and modified wallet software), extract the transaction, rebroadcast or replay it into the BCC chain, effectively making Alice pay him the same amount of BCC coins as well. Sounds scary right? Maybe we really need some replay protection right?
Well, not really. Lets break this scenario down. In a post split world all participants in the network are going to fall into 2 categories. Those who care about the value on the minority (cheaper) vestigial chain¹, and those who don’t. If you care about your balances in both, then you will be running software on both chains and run separate wallets for both of them. If you don’t, then you will just stick with your existing wallet and not have to do anything. Let’s examine all the scenarios that can happen in an 2 party commercial exchange:
- Alice cares about split coins, Bob does as well
- Alice doesn’t care, Bob does
- Alice cares, Bob doesn’t
- Alice and Bob both don’t care
In the first scenario, Alice will have coins separated using different wallets, and so will Bob, so if Bob asks Alice to pay for the carpet in BCU, she will know to use her BCU wallet. This wallet will be smart enough to ONLY pay coins that are unique to BCU and are not replayable to the BCC chain, because this wallet does the job of ensuring this (see this article² if you are interested how). The transaction that Alice sends to Bob cannot be replayed. There is no room for making a mistake.
In the second case, as Alice doesn’t care, she doesn’t know which chain her wallet is on, all she knows is that she has ‘Bitcoins’. Bob asks her to pay in BCU, and tells her that it is one of the offshoots of the original BTC. Alice shrugs and asks if her BTC is accepted, and Bob confirms that it is. (because Bob cares, he knows that BTC from before the fork is definitely good on the BCU chain). The transaction that Alice sends Bob, IS actually replayable* on the BCC chain, so Alice has given Bob both BCU and BCC of the same amount. Bob got a nice tip! Well, effectively that’s what it would be, but as Alice doesn’t care about this value that she may be holding, it isn’t a loss for her. She made the decision to ignore the minority chain value, likely because its value was so low compared to the majority chain it wasn’t worth the effort. So “keep the change Bob!”.
In the third case, Alice wants to preserve her value on the minority chain, and thus keeps her wallets separate. Bob asks her payment in ‘bitcoins’, he doesn’t know which. Alice, being the one who cares, has done her research and knows which wallets support which chain, so she checks the wallet and payment processor that Bob is using, and finds out that it accepts the majority chain, BCU. She pays with her BCU wallet appropriately. No problem here.
The most interesting scenario is the last one, where both Alice and Bob are oblivious. There are therefore a couple of sub-scenarios:
- Alice pays with BTC, when Bob is using either BCC/BCU wallet (prefork BTC paid)
- Alice and Bob both are using BCU wallets
- Alice and Bob both are using BCC wallets
- Alice pays with BCC, when Bob is using a BCU wallet (mismatch)
- Alice pays with BCU, when Bob is using a BCC wallet (mismatch)
In the case #1 where Alice pays with BTC (prefork coins) Bob sees the payment and is the same as scenario #2 from before (Bob gets an unknowing tip).
The interesting cases are where Alice and Bob are both using mismatched wallets (#4 & #5), as obviously the transaction would go smoothly unbeknownst to them if they were using wallets on the same chain in case (#2 & #3).
In the mismatched case, Bob would show his QR payment code, and Alice would scan it. But the payment transaction would never arrive! That is because Bob’s wallet is listening on a chain where Alice’s transaction is not valid, because it cannot be replayed due to incompatible histories². Bob would wait a bit, then tell Alice that he didn’t get the payment. She will likely fall back to using her credit card to buy the carpet. Bob would have received some BCU/BCC that he wasn’t expecting, but he doesn’t see it, nor care, as he is running his business on one of chains which is ignoring that payment that Alice made to him. In this case, as Alice suffered a financial loss, it would likely be onus of Bob’s or his payment processor to refund Alice’s coins back to her address. This is one case which bears some attention, and can be easily avoided if Bob is clear which chain his payment processor or his wallet is running on, informs Alice of it before she makes payment. In fact, if the buyer isn’t sure which coins their wallet holds they should probably not use it. For this reason if you run a business or payment processor, you should always follow the longest (PoW) chain. More on this later.
Reasons why you don’t want Replay Protection
Now we get to the more shadowy reasons why some would insist on replay protection be done for any hard fork. They all stem from reasons that would make executing a hard fork much harder, and thus supports the argument that Hard Forks are hard and dangerous.
Firstly, SPV wallets/nodes would need to be upgraded if replay protection (and the needed transaction format change) were to be applied. As this upgrade would be time consuming and obligatory, a majority lead hard fork would see no reason to force an additional upgrade of wallet software on the users.
Secondly, as a practical matter, there is no possibly way to determine the existence of all minority forked ledgers which may be based off of Bitcoin at any given time. To expect the majority chain client to change their transaction format each and every time a minority client which has in secret forked their own chain off of the Bitcoin blockchain would be infeasible and intractable. This, they will say, is why hard forks are so hard! (circular argument) Practically speaking, if any chain were to desire replay protection or prevent cross transaction migration the onus should be on the minority chain to provide this feature. They are the ones which need replay protection to prevent the majority PoW chain from 51% attacking them anyhow, so it is in their best interests.
Finally, most importantly, is that the replay ‘attack’ is actually a necessity in order to allow for coin spitting! Coin splitting is the process by which you process your own coins and separate BTC into BCU and BCC separate addresses, so that you can safely use both coins without chance of mixing them up. It is a prerequisite that every Alice or Bob who cares about the value on both chains to process their coins via a coin-split to be able to protect the value on both. Replay protection would greatly complicate this process unnecessarily, for arguably little gain, as a determined party would just unpack and the transaction on one chain and rebroadcast it on the other chain in the new format just the same.
In conclusion, we have laboriously enumerated all of the possible outcomes of a commercial transaction in a split fork world, and identified only 1 case where both participants in a trade are oblivious to the fork that would result in some economic loss. It is precisely because of this chance of loss that the logical behaviour of mostly all the economic actors in the real economy would clearly follow Nakamoto Consensus³ and follow the longest PoW chain, and not some misguided notion of which chain is more ‘valid’ (and following the minority hashpower chain) where validity is determined by developers pushing their version of software which defines it. Satoshi elucidated this best in the original whitepaper:
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
— Satoshi Nakamoto, Bitcoin Whitepaper, 2009
Replay protection is not needed for the majority chain. What is needed is that we educate merchants and real businesses the importance of staying on the longest proof-of-work chain. Those that don’t will give a poor experience for their customers, and perhaps face support or legal issues if those angry customers come back demanding refunds. You having read this article are now probably much better equipped at managing the fork when it happens. As always, thanks for reading, and stay skeptical.
* While technically replayable, in reality the minority chain network would likely naturally partition itself from the majority chain network at the P2P layer. This is due to technical reasons stemming from the fact that nodes actively ban ‘misbehaving’ nodes, and each chain’s nodes would see the other as misbehaving.
¹ The minority chain being a vestigial barely useable chain is a theory with merit. Some calculators showing just how unuseable it would be can be found at https://hardfork.cafe/
² see Splitting Bitcoin, Jerry Chan, Mar 2017
³ Consensus mechanism introduced in the original whitepaper, which is that everyone follow the longest proof-of-work chain. (not one in which an intermediary dictates what is ‘valid’)