A key tenet of the value proposition of Bitcoin (BSV) is that it is stable, and mandatory replay protection damages this. The only benefits to mandatory replay protection are illusory. We should not add mandatory replay protection into Bitcoin. Instead, we should keep the protocol stable, which will improve confidence in Bitcoin.
The arguments for mandatory replay protection are as follows:
- “Some exchanges will only add Bitcoin if we add replay protection.” False. Every exchange will add Bitcoin as it grows in adoption, or they will go out of business. The correct way to get exchanges to add Bitcoin is to increase adoption and exchanges will follow. The best way to get adoption is first and foremost with a stable protocol. Do not make the error that adoption comes from exchanges. Adoption comes from utility, and that means sending transactions, not trading on exchanges. (Most exchanges will add support due to competition from other exchanges even before significant adoption anyway.)
- “The only safe way for exchanges to add Bitcoin is if we add replay protection.” False. Replay protection does not need to be mandatory and it does not need to involve a hard fork—replay protection can be done voluntarily right now. Exchanges have already added Bitcoin safely by adding voluntary replay protection with coinbase transactions and/or opcodes that are only valid or invalid on Bitcoin. Every remaining exchange will do so as well or they will go out of business.
- “We need to restore the original sighash algorithm so we can restore the original protocol.” False. The only details that matter with the protocol are those that impact the economics. The fork ID is an irrelevant property of the sighash algorithm which doesn’t affect the economics. Changing the protocol is what affects the economics, and it affects it for the worse. The way to preserve the economics of Bitcoin is to keep the protocol stable, which means not adding mandatory replay protection.
- “We need to restore the original sighash algorithm because that’s what really constitutes Bitcoin.” False. A key tenet of the Bitcoin protocol is that it is stable over centuries so that businesses can rely on it for real contracts like loans that last for decades. This argument is like saying, “Bitcoin has changed in the past, so it must change again now,” which is a logical fallacy. To restore some arbitrary properties of the original code with a hard fork to be more like the “real” Bitcoin is dangerous mythology that comes at a real cost to real businesses today.
- “In order to keep Bitcoin stable, we need to change it one last time.” False. This is illogical. Changing the protocol is the opposite of a stable protocol. Keep the protocol stable so that businesses can know they can rely on it.
Even the mere assertion of adding mandatory replay protection itself comes at a real cost to real businesses, like ours. It took some time away from our product to produce this article to remind the Bitcoin community of the central tenet. Do not change the protocol. Keep the protocol stable for centuries. The only changes we should ever make are improvements to the cryptography if the hash algorithms or signature algorithms are ever broken. If they are never broken, then we never change anything.
The value proposition of Bitcoin is that it solved the problem of sound money for the world on Day 1 and is reliable for every business use-case now and indefinitely into the future. To change the protocol is a deep error that damages the central value proposition for real businesses. Instead of facilitating adoption, it will decrease adoption. It is a needless risk.
The fact that some exchanges and wallets have asked for replay protection is an opportunity in disguise. Do not give it to them. Instead, show the world that Bitcoin is stable. We do not change the protocol just because people ask. This is a signal that Bitcoin is indeed stable. Confidence in Bitcoin will improve if we don’t add mandatory replay protection.
The only thing we need to do right now is: 1) Remove every DOS attack protection limit from the software, 2) Scale the software to gigabyte sized blocks, 3) Get adoption. Everything else is a distraction.