A guest post written by and reposted with permission of: Shammah Chancellor
Hello, my name is Shammah Chancellor, I go by micropresident within the Bitcoin Cash community. I use to work on Bitcoin-ABC as a developer.
Recently, Automatic Replay Protection (a.k.a. the Poison Pill 👻) has become controversial, with some people seeking to get rid of it. I wrote the specification for this protocol rule. As such, I’ve been asked by a few different Bitcoin Cash users to explain this functionality to them. Hopefully this article appeals to a wider audience.
“Automatic replay protection” is critically important to the future of Bitcoin Cash. It was unanimously asked for by exchanges. Without it, routine protocol upgrades would be practically impossible due to the amount of extra work required by exchanges, wallets, and other developers to smoothly enable.
This is because, during an upgrade, if a minority of individuals do not agree with the new rule-set then they may continue mining a chain using the old rule-set. However, the blocks produced will not be valid under the new client, and not seen by the exchange running the new node software. When this happens, transactions will still continue to be valid on both the upgraded chain, and the legacy chain under most conditions.
Transactions, that are valid on both of these persistent chains, can be rebroadcast by nefarious individuals to potentially steal money from end-users and exchanges. For example, during the Ethereum Classic fork, some individuals would deposit coins which were uniquely Ethereum to an exchange, withdraw it, and replay that transaction on the Ethereum Classic chain in order to obtain “free” ETC from exchanges.
Now, if this happens, and the minority chain becomes valuable, the exchange will have lost money. The exchange will no longer be able to property credit customer accounts for the fork. As a result, when protocol upgrades happen, without any replay protection, then exchanges must halt deposits and withdrawals for that coin.
In order to resume trading, they need to ensure their reserves are “split” (meaning that their funds become unique to each of the new chains) before offering withdrawals. Doing this is a somewhat complicated process and cannot be made fully automatic due to the steps involved.
As such, the ABC team was told by many exchanges that they would not continue to support protocol upgrades, if there was no easy-to-implement replay protection. The result was the implementation of Automatic Replay protection.
The basic premise of implementing replay protection in the node, rather than indirectly by exchanges, is to include some data indicating upon which fork a transaction should be valid when being signed. In the initial August 2017 fork from BTC, this was done by introducing a signed field called a “fork identifier.” Bitcoin Cash uses fork identifier of “0” since Aug 2017.
It would be possible to meet the needs of exchanges by continuing to increment for each protocol upgrade. However, implementing replay protection like this also requires updating every wallet to include the new fork identifier. This puts a burden on all wallet users, in addition to exchanges and miners.
During the first fork, this was an acceptable cost, as we were launching a new cryptocurrency. However, doing this during routine upgrades would cause significant loss for end-users who forget, or fail to upgrade their wallets in a timely manner.
Ultimately, the better solution which we came up with was to cause the old bitcoin nodes to change the fork identifier every 6 months instead. Thus, software that didn’t upgrade would now use a new fork identifier, ensuring that transactions would not be valid on both chains. This stops loss of funds through replay attacks. This is called “Automatic Replay Protection.”
That caveat here, is that there does need to be minimal upgrades every 6 months — even if it contains no other change than to reset the fork identifier. However, this is an acceptable situation to ensure that the software can be upgraded in the future. No set schedule for upgrades is why BTC is stuck with soft-fork upgrades, and ossification of the protocol.
Additionally, because everyone has to upgrade their nodes every 6 months, there can be no complacency in participating in the Bitcoin Cash network. And as there cannot be complacency, it means that there is a potential for users, assuming they can reach consensus, to switch to new node software.
So, in summary, Automatic Replay Protection is important to, ensure protocol upgrades continue to be possible by:
- Stopping the loss of funds from exchanges.
- Making exchanges feel reassured during protocol upgrades.
- Ensure that every 6 months, users have the willful intention to keep running the *SAME node software — and to run new software if they want.
It seems that, those individuals calling this functionality controversial are simply not aware of the purpose and have become a victim of Chesterton’s fence.
Although, in the past the individuals (i.e. nChain and BSV) were attempting to force a different brand of Bitcoin on users without their voluntary participation in the power shift. I hope that’s not the case again.
P.S. It was pointed out to me that some people are saying ARP doesn’t matter because none of the other nodes use it, and they’re still in consensus.” The reason that’s the case, is these nodes are not widely used by miners and exchanges — and if they were to fall out of consensus it doesn’t have much impact. Remember, this is functionality for commercial operations, and only matters in the case that there is an intentional coin split.
P.P.S. It seems to me that part of the arguments for removing it is that it “doesn’t matter,” or that it “doesn’t do anything.” If that’s the case, then why bother removing it? If that’s not the case, and it is being removed, then the original claim seems to be disingenuous…
About Shammah Chancellor
Shammah Chancellor is an open-source software developer and entrepreneur who previously contributed to Bitcoin ABC and worked at Cloudflare. His current focus is Stamp. Stamp is a new BCH wallet utilizing Layer-2 tech to implement Web3 support on BCH. Connect with Shammah on Twitter at @micropresident or on Linkedin at https://www.linkedin.com/in/schancellor/.