The need for universal opt-in replay protection

SegWit2x got cancelled, and with it probably the most heated "battle" in the Bitcoin space thus far draws to a close. There are many lessons to be learned from this ordeal as well as some other forks that are happening around Bitcoin - what constitutes "consensus" in the community, how will the future forks be handled and so on. One important aspect I haven't seen discussed as much currently is the ongoing issue of fork-proof replay protection - a feature that caused some controversy by its absence in SegWit2x and made Bitcoin Gold a laughing stock when they created a bounty for it very close to their forking date.

Strong vs opt-in replay protection

There is an important distinction to be made between strong and opt-in replay protection. When a fork occurs, the former is always on and prevents any transaction on one side of the fork from being valid on the other side of the chain. Bitcoin Cash has strong replay protection for example.

Opt-in replay protection on the other hand is optional - you can create a transaction that won't be valid on the other side of the fork, but you are also able to have a transaction that is valid on both sides.

Strong replay protection is useful when you want to split from the main chain and remain an independent project. However, it can be detrimental when the changes you're proposing are meant to be an upgrade to the current code rather than forking off into a new project. This is why SegWit2x didn't opt to have a replay protection - it was meant to be an upgrade to the Bitcoin project and be the only version used. The only way to achieve that was to make it hard for both sides of the fork to coexist.

Problem with opt-in replay protection

While opt-in replay protection sounds like the proper way to go, there is one important problem to consider - how do you implement it in a way that will apply to all future forks?

In a perfect world, every fork would be carefully maintained and it would make sure to make its opt-in replay protection create transactions only valid on its own chain. However, as Bitcoin Gold and other projects have proven - we can't rely on forks being managed competently. Hence, we need a universal opt-in replay protection, one that is agnostic to any future forks (even those that don't honour any replay protection whatsoever) and creates transactions that will be only valid on one chain.

Universal opt-in replay protection

A fork that splits off from the main project can be caused by any alteration to the protocol. There is no universal way to differentiate between both sides of the fork ahead of time save for one - the blockchain history. You can mimic anything about the code, even pretend to be some different client, but for certain at some points the blockchains will diverge - otherwise we wouldn't be dealing with a fork. Once that is done, the data can be used to implement the replay protection.

If one could flag a transaction to only be valid if a given block hash is present in the blockchain, that would be enough to ensure it will always be possible to safely move coins around on any fork that might occur in the future.

If both sides of the fork honour that flag, only one side will include the transaction in the block. Do this on both sides and the coins will be safe to spend on two sides of the fork.

If only one side of the fork honours the flag however, the replay protection could still work, albeit with some limitations. You would need to create a transaction with the flag on the chain that doesn't honour it. This way the chain will include the transaction in its blockchain, but the main chain will reject it, since it would not recognise the block hash. After the first transaction is confirmed, it would be safe to spend the coins on the other side of the fork.


It is possible to implement a universal opt-in replay protection that will still be effective even if only one side of a given fork will respect its rules. This should be sufficient to protect one's bitcoins in an event of a possible future bitcoin fork.

The proposed implementation is rather simple and elegant. I came up with this idea when contemplating SegWit2x awhile back, but then became pleasantly surprised when I found out someone else already proposed it as a BIP115 a year before :). It's not part of the main codebase yet, but maybe by the time next fork rolls around we'll have something to protect our bitcoins with...


What is Bitcoin in the light of hard forks?

This year has been one of the more controversial years for Bitcoin thus far. We have already seen a number of important forks happen - SegWit, Bitcoin Cash and Bitcoin Gold, and we're scheduled to witness some other forks soon - Bitcoin Cash doing a hard fork, SegWit2x looming ever closer, and we might even see some emergency PoW change hardfork in response to SegWit2x. Amidst all of that, many people are asking themselves, debating and fighting over an important question - "What is Bitcoin?" (that iconic question).

The power of the name

Earlier this year, there was a small debacle as to what Bitcoin Cash should be called. It seems that some of its opponents wanted to dismiss the fork by calling it "Bcash" to further distance it from the Bitcoin project. It seems the "Bitcoin" name by itself holds value like any other brand, otherwise we wouldn't have so many projects using it:

How many Bitcoins do we have? (source)

In response to Bitcoin Cash being called Bcash, some supporters of that project started calling Bitcoin Cash by just "Bitcoin", and referring to the SegWit side of the fork as "SegWit Coin".

While at the start it might not seem like much, a definition of what "Bitcoin" is and which side of a fork gets to call itself that is really important. Bitcoin is a currency with over 125B USD market cap, a liquid market on numerous exchanges, and countless of projects using it, many of whom would barely be able to follow what's going on in this debate. A fork of Bitcoin, on the other hand, has to start out with nothing and build up that market almost from scratch.

This is why contentious forks are so problematic and why such a simple thing as replay protection is controversial - whoever wins in the fork and gets to call itself "Bitcoin" will be the project that matters, while the loser won't matter anymore. A fork with a hard replay protection is easy to dismiss as an altcoin, while one without is much easier to pass on as an upgrade to the protocol, as Bitcoin has historically never done replay protection (while it seems Ethereum might be getting that as a standard in the future).

So what is Bitcoin, really?

With all of those forks past and future, many people have to ask themselves - "What is Bitcoin, really?". Gavin Andresen's definition has been a good guide so far:

“Bitcoin” is the ledger of not-previously-spent, validly signed transactions contained in the chain of blocks that begins with the genesis block (hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f), follows the 21-million coin creation schedule, and has the most cumulative double-SHA256-proof-of-work.

It might, however, be worthwhile to start drilling down the definition and listing all of the important semantics that have or might be important in the future.

So Bitcoin could be defined as:
  1. A blockchain
  2. Beginning with the genesis block hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
  3. Containing only validly signed transactions
  4. Containing only not-previously-spent transactions
  5. Containing no more than ~21M coins
  6. Following the ~130 year coin distribution
  7. Continuously, publicly mined
  8. Double-SHA hashed
  9. With a difficulty adjustment every 2016 blocks
  10. Mined using a PoW algorithm
  11. Following the chain with the most cumulative work
  12. With a block limit of 1MB
  13. ...

There are many such nitty-gritty details to list and rank. An important exercise for a lot of people is to rank these various features, and in case of a contentious fork - figure out which of those features might be changed.

So for example, if Bitcoin Gold is creating a fork that changes the PoW algorithm and doing private mining for awhile, versus Bitcoin Cash changing the block limit and changing the difficulty adjustment algorithm, we have forks that change the features 10 and 7, vs 12 and 9. Following this ordered list, Bitcoin Cash would be less contentious (which is not to say - not contentious at all) as it alters features lower down the list.

So would Bitcoin be Bitcoin under Script being changed to Simplicity? SegWit2x changing the block size? A fork that changes the PoW? Which part of the fork would be "more Bitcoin" than the other?

Of course, there is more to a fork than just such rules - there is a lot of politics involved, and sometimes a more controversial fork still remains dominant. Ethereum's DAO fork for example meant the "main" chain violated a very important rule - containing only valid transactions, but that side of the chain is still a lot more widely used than the "purer" alternative - Ethereum Classic.


Battling over which side of the fork is "the real Bitcoin" is more than just fighting over a name. It is the battle for market dominance, wide acceptance and legitimacy in the eyes of the laymen. The winner will be the world's best know cryptocurrency, while the loser will be hardly talked about outside of the crypto circles.

Seeing which side of the debate will endure the upcoming forks will definitely be a seminal point in the story of Bitcoin.