The Costs of Replay Protection via Blacklisted Address

Segwit2x’s (lack of) replay protection has been point of particular controversy surrounding the upcoming hardfork in November. Critics have claimed that the 2x fork will be needlessly creating chaos in the ecosystem without proper protection. Proponents of the NYA have responded by stating that replay protection would gone against their intended goal of keeping the community together on one chain after the fork.

In recent news, Jeff Garzik has merged opt-in replay protection on the btc1 repository.

Jimmy Song has already done a terrific job of outlining how the replay-protection scheme works and how it can be used. This is strongly recommended reading, and this article will not try to improve upon his explanation.

There is another consideration, however, that warrants attention — what will the network-wide side effects be?

There are several points worth mentioning:

One-Way/Opt-In vs Two-Way/Mandatory

The first is the general decision to favor a one-way opt-in method, rather than compulsory two-way protection.

As detailed by Eric Voskuil’s piece Fragmentation Principle:

Upon the split an original unit becomes two units, each with decreased and proportional utility in relation to the original. With bidirectional mandatory replay protection each can be spent at no additional cost. Otherwise the need for self-protection discounts units of the unprotected chain(s).

When a coin splits, the two separate economies still have a shared total utility. The more difficult it is to split users’ coin and spend them, the more this utility decreases.

In short, the current proposal harms not only the legacy chain’s utility, but also the utility of any Segwit2x coins.

The other concerns regard the specific decision to use a blacklisted address. It would be easy to criticize the very concept of a blacklisted address as going against the anti-censorship ethos of Bitcoin, but this piece will attempt to address only the direct and well-understood problems that can arise.

Bloating the Legacy Chain

There is the fact that it will add wasteful bloat to the legacy chain’s UTXO set and blockchain.

If you’ve ready Jimmy Song’s article above, you will know that splitting coins requires making a transaction that moves your coins and sends any amount (can be 0 satoshis) to the blacklisted address. This means that every time someone splits there coins, there will be another useless UTXO added to the current set.

These UTXOs needn’t stick around forever, since the blacklisted address has a publicly known private key. But assuming that someone pays to sweep up all the dust UTXOs caused by the blacklisted address, this will simply redirect the burden into more wasted blockspace.

Risk to Segwit2x Users

Additionally, the blacklisted address adds risk to users of the Segwit2x chain. This was posed as a homework challenge by Peter Todd on twitter, which was quickly solved by David Harding.

The basic idea is that a user opening up a lightning network channel must have software that guards against accepting any transaction involving the blacklisted address, or they will expose themselves to theft.

Bi-directional channels require each party to exchange several transactions that, ideally, will never be broadcasted to the blockchain, but are kept as insurance in case the other party tries to cheat them. These are called commitment transactions.

If one of the parties accepts a commitment transaction that involves the blacklisted UTXO, they will have opened themselves up to theft from the counter-party.

This can, of course, be addressed by updating lightning network software to specifically guard against this issue, but it does add further complexity that could otherwise be avoided.

There is also no reason to assume that this type of risk won’t extend to other technologies that rely on valid transactions that don’t actually hit the blockchain.

Other Options are Available

Now, none of these issues are catastrophic in and of themselves. But the fact remains that they are all entirely avoidable. The hardfork has many other options to choose from, several of which were pointed out by Gregory Maxwell:

Instead they could have made a ~2 line change to allow an extra ignored bit to be set in the sighash flags, or a simple additional serialization so that you could make S2X only transactions. They’re making a hardfork in any case, so it would be trivial to allow a new transaction style that Bitcoin doesn’t accept.

It is laudable that the btc1 team has moved from no replay protection to at least one option. But considering the known risks and clearly superior alternatives, it comes across as an odd choice, at best.