Why Automatic Replay Protection Exists

Avatar for micropresident
3 years ago

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:

  1. Stopping the loss of funds from exchanges.

  2. Making exchanges feel reassured during protocol upgrades.

  3. 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...

28
$ 21.61
$ 5.00 from @Cain
$ 4.74 from Anonymous user(s)
A
$ 2.00 from @Cheshirecat
+ 19
Avatar for micropresident
3 years ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

Thank you for taking the time to write this. Much appreciated.

$ 0.00
3 years ago

Excellent article

$ 0.00
3 years ago

Outstanding explanation. The hero we need. Thank you!

$ 0.00
3 years ago

It doesn't work in practice. You can't reset the fork identifier to 0 for Bitcoin ABC every six months and simultaneously force anyone you disagree with to not do the same. You cannot control the consensus rules others choose. And because of the "extra work required by exchanges, wallets, and other developers", there is a significant incentive to keep the 0 identifier, unless you are absolutely sure you will be a minority.

For this reason, Automatic Replay Protection failed miserably at the only time in its history it would have been useful: when Bitcoin SV split off.

Without theoretical benefits materialising in practice, the costs (a rigid upgrade schedule with forced software updates even if there is no change, users having it activate unintentionally) are probably not worth it.

Either way I am not advocating for Bitcoin ABC to drop Automatic Replay Protection. Every implementation can safely make their own decision on this issue. If Bitcoin ABC likes it, they should keep it in. If all other nodes don't like it, they should keep it out. Automatic Replay Protection never activates if people keep their node up-to-date, and developers can decide for their own nodes what should happen to them when they are not up-to-date.

$ 2.00
3 years ago

bingo! this is the correct answer. the poison pill does not fulfill its stated purpose at all.

$ 0.00
3 years ago

Ahh, but, it does tell you which implementations are trying to harm the community by intentionally disabling the safety feature (or calling for it's removal).

$ 0.00
3 years ago

If the safety feature has no benefit in practice, as I explained, then removing it will do no harm.

$ 0.00
3 years ago

BSV removed it to harm BCH. Why would anyone else remove it before taking a risk of splitting the chain? Answer: to harm BCH. I am pretty sure your team would be unwilling to commit to keeping your nodes in consensus with ABC. I may be saying that wrong, but, I think people understand what I am trying to say. Would you all be willing to promise there will be no split no matter how bad ABC behaves? Of course not.

$ 0.00
3 years ago

From my understanding, while the ARP works for the intended purposes, it isn't without side-effects and one of the side-effects relates to governance in a way that some does not agree with.

I personally feel that it would be better if there was a clear alternative solution to the original problem proposed and agreed upon before removing the ARP.

However, since this doesn't seem to be a consensus rule in the sense that only ABC (and now BCHN) implements it, I think this should be seen as a node software feature: ABC has chosen to voluntarily add code to their software that forks themselves off the network unless the operator updates in order to remain.

Sadly, due to the weak decentralization of node software usage in the wild, it also has the effect that if we do nothing, then while ABC willl fork themselves off of the network, they will also become a majority fork and since exchanges and miners use their software it's likely that people would not recognize the original as the original.

Given the claim that the need for this came from exchanges, I urge BCHN to reach out to and talk with exchanges about this issue before completing their removal of the feature.

I don't like the governance side-effects of the ARP, but I do see the value it provides.

$ 0.05
3 years ago

if we do nothing, then while ABC will fork themselves off of the network, they will also become a majority fork and since exchanges and miners use their software it's likely that people would not recognize the original as the original.

It is impossible to not notice that automatic replay protection actually activated on a chain. It suddenly invalidates all mempool transactions with a signature and breaks all wallet software. This would be a complete disaster. As we saw previously when some miners forgot to upgrade, the result is a chain of empty blocks. It is highly implausible that people would recognise this as the "real" Bitcoin Cash chain.

To avoid this disaster, every six months, ABC removes the replay protection it added six months earlier. ABC might stop adding replay protection some day but they will certainly never stop removing it before activating.

while the ARP works for the intended purposes

It doesn't work.

$ 0.00
3 years ago

ABC has chosen to voluntarily add code to their software that forks themselves off the network unless the operator updates in order to remain.

Ya, we do that every 6 months to upgrade BCH. If you don't like the idea of doing regular upgrades that are planned ahead, argue against that instead of confusing the issues to make it seem like it is unusual. It's not unusual on BCH. Those who are behind the call for less upgrades sound to me like they want to slow down BCH progress while pretending that that is not their goal.

$ 0.00
3 years ago

Well its quite self serving.

All the exchanges and miners were using Bitcoin ABC

The exchanges, miners and wallets were worried about the possibility of users losing funds because of accidentally forgetting to upgrade in accordance with ABCs aggressive 6 month hard fork schedule and refused to do so.

ABC includes automatic replay protection, meaning they can't lose funds but their software will also cease functioning if they fail to upgrade to the latest ABC client. As a result now all exchanges, miners and wallets do not have a choice about participating in ABCs six monthly hard forks.

All this seems to cement ABC as the reference client.

The right response for ABC at the time would have been to not go ahead with a 6 month hard fork schedule as resistance was too high but instead negotiate a time, 1 year or 2 year, that was acceptable to the exchanges, miners and wallets to go through the burden of hard forking.

Without a scheduled hard-fork + automatic replay protection, 'aka poison pill', the majority need to be convinced by ABC to upgrade to a new hard forking client. In the current situation everyone has to upgrade, and the power was tilted too much in ABCs favor.

Inspired from: https://www.reddit.com/r/btc/comments/hd0evt/why_automatic_replay_protection_exists/fviqnzm?utm_source=share&utm_medium=web2x

$ 0.01
3 years ago