No2x: No Replay Protection

On the night of March 11th, 2013, Bitcoin experienced an unexpected network disruption caused by inconsistencies in the software implementation. Over the course of the next few hours several major Bitcoin services and exchanges suspended operations until stability was restored. In total the disruption lasted only a few hours, but it remains the most significant blemish on Bitcoin’s impressive operational record. Almost five years later, it is still a topic of frequent discussion.

On or about the night of November 15th, 2017, Bitcoin will experience a much larger and expected network disruption caused by the activation of the Segwit2x hard fork. This disruption may last up to a few days. Many services and exchanges have already announced plans to suspend operations until stability is restored. Coinbase, Blockchain, Xapo, Bitgo, and Bitpay are among the companies planning extended downtime. Blockchain goes so far as to advise users to switch to Ethereum. The difference is this time the disruption is entirely avoidable.

Miners, Bitcoin Core developers, companies in the industry, and many participants in the ecosystem have worked hard for 9 years to make Bitcoin as secure and stable as possible, to keep it operating consistently and to minimize the chance of financial loss. All this effort is being tossed aside and a major disruption created, but for no good reason. With the simple addition of replay protection, all of these services would have been able to continue operations continuously through the fork. All the same market forces and user decisions would have led to the same outcome, but in a much cleaner fashion.

Instead, replay protection is being painstakingly implemented at the individual company level with weeks of engineering effort. And the downtime will be required because transactions will have to be manually manipulated in order to create outputs spendable on only one of the chains.

I don’t understand the reasons that the Segwit2x fork does not include replay protection, but I believe the entire community is at fault for not more clearly and loudly demanding it. Regardless of any desire for larger blocks or to move forward with a rule change without waiting for greater consensus, regardless of any belief that the situation will quickly resolve with one dominant chain, we should have insisted that the signers of the NYA implement replay protection. With it, this downtime and potential for financial loss could have been completely avoided.

The right way to do a hard fork of Bitcoin, especially one that doesn’t have near universal consent, would be to split completely cleanly: new network magic, new address format, and mandatory 2-way replay protection. For various reasons the BTC1 project does not want this. So lets put aside this wishlist of desired behavior and focus on just optional 2-way replay protection.

What is optional 2-way replay protection?

• Replay protection allows you to make a transaction that is valid on one chain but not on the other.
• 2-way means it is possible to do this in either direction, create a transaction on the original Bitcoin that is not valid on the 2X fork and vice versa.
• Optional means no transaction creating software has to change. The use of replay protection is only an additional option. The argument against mandatory replay protection from the BTC1 project is they didn’t want the installed base of wallet software to have to make changes. With optional protection, changes are only needed if you want to treat the two assets differently.

There is no downside to implementing optional 2-way replay protection. There is no argument against it. Any company that is still part of the the NYA needs to take the time to reflect on that and ask themselves why they are part of creating this completely unnecessary network disruption. The largest disruption in the history of Bitcoin.

Replay protection is easy and safe:

• Transactions valid on 2X only can easily be created with the use of a SIGHASH_FORKID similar to that implemented in Bitcoin Cash. This is literally a 3 line patch, plus a line or two for activation logic.
• Transactions valid on original Bitcoin only were already implemented in the BTC1 project and then inexplicably removed.
• Much more elegant designs for transactions valid on original Bitcoin only were readily available using tweaks to the transaction version or sequence fields.
• Concerns about payment channel vulnerabilities apply to any soft forks and just go to show these issues require careful thought, they are not applicable here though, because there is no installed base of lightning applications. They could also have been mitigated by using transaction version which would already be non-standard.

At the very least, optional 2-way replay protection is strictly superior to the current situation of no replay protection. There is no excuse for not having it. It’s hard to conclude as to why BTC1 doesn’t. Incompetence? Intentional desire to cause chaos? Or just gross negligence with the duty of care owed to the Bitcoin system?

I leave you with the answer received any time anyone has asked them this question:

*silence*