RFC: AllowReplay–Safer Splits for Bitcoin Cash

This is a request for comments on the AllowReplay draft specification. AllowReplay is a feature which allows users to opt-in to replay protection on a per-signature basis. Implementation of AllowReplay is strictly beneficial to the implementing side of a split, and it may be implemented by any or all sides.

This blog post provides some background, but you can also skip to the draft specification on GitHub. I would appreciate your comments below or on the GitHub issue tracker.

Understanding Replay Protection

When a cryptocurrency splits, each resulting segment of the network continues building on its own version of the global transaction ledger. Holders with balances suddenly have balances on each side of the split, and each resulting cryptocurrency can be used or sold independently.

Since both sides of the split typically remain very similar and spend from the same set of previous transactions, without intervention, most transactions from one side can be “replayed” on the other side: if you make a payment on one network, the recipient could send your transaction to the other network, claiming an equal amount of that currency too.

Replay protection is the broad term we use for mechanisms which prevent “replaying” transactions from one side of the split on the other. Replay protection makes splits much easier for users by helping them to move funds on each side independently. Without replay protection, users often must 1) have deep technical knowledge to separate their funds or 2) rely on a supporting service or exchange to separate funds on their behalf.

Replay Protection for Chickens

Naively implemented, replay protection is a disadvantage to the side of the split which implements it.

For example, in a two-way split, there are three demographics of users:

1. Partisans for side A of the split
2. Partisans for side B of the split
3. Indifferent users — users who are not paying attention or don’t care which side “wins”

If side A implements reply protection by requiring transactions to use a new version number, this will successfully prevent side A transactions from being valid on side B and vice versa. This is very helpful for users, whose wallets can now easily choose between side A and side B for each transaction.

However, by doing this side A has forfeited the demographic of indifferent users, who have not upgraded their wallets or node software, and will now continue operating by default on side B. This hands side B a large part of the pre-split network effect, and hurts side A’s chances of being the majority side of the split.

As this demonstrates, naively implemented replay protection is a game of chicken: it’s best for everyone if replay protection is implemented, but each side hopes the other side will implement it first.

Gradually Activated Replay Protection

One replay protection strategy which doesn’t result in this dysfunctional scenario is Gradually Activated Replay Protection (GARP). Paul Sztorc’s GARP — Toward Hard Forks that Don’t Suck is a great analysis of the idea and game theory. To summarize, GARP offers several advantages:

• It is strictly an advantage to the implementing network, and remains valuable when implemented by competing forks.
• Indifferent users transact on both chains by default, reducing their effect on the market.
• Large actors are strongly incentivized to offer support for popular forks, even if those forks fail to attract a majority market price.

If the Bitcoin Cash ecosystem can develop a standard for this sort of opt-in replay protection, it will encourage valuable technical competition and open source development (lowering switching costs), provide stronger market-based checks on ecosystem actors (reducing the risk of future aggression toward miners and developers), and give users greater control over their funds during contentious splits.

AllowReplay uses this approach. With AllowReplay, future splits of Bitcoin Cash will be more competitive, less political, safer for users, and easier for large actors to support.

The AllowReplay Proposal

This proposal is aimed toward either or both sides of the November split (if one occurs), and it would be valuable to implement even if no split occurs.

Both networks should continue to support the Re-playable Fork ID (RFI) 0x000000, and if activated, each network should also support a new Network Fork ID for the duration of the next upgrade period (until May 2021).

In the initial draft, I’ve proposed a Network Fork ID of 0xee7782 for Bitcoin ABC (from bitcoincash.org@ee7782) and a Network Fork ID of 0xee5d75 for BCHN and the other implementations (from bchn-sw/bitcoincash-upgrade-specifications@ee5d75). I think these are the “most canonical” choices, but please let me know if I’ve missed a better 3-byte, pseudorandom identifier for either upgrade proposal.

Thanks for reading! I would appreciate your comments below or in the GitHub issues tracker. You can also message me on Twitter.