In July 2016, a contentious hard fork split the Ethereum network into two. A month earlier, the DAO, a decentralized venture capital fund, was hacked and lost 3.6 million Ether of user funds.

The Ethereum development team along resolved to modify the rules of the protocol with a hard fork so that investors in the DAO could retrieve their money, essentially traveling back to a point in time on the chain before the hack occured. Not everyone, however, accepted this hard fork. Dissenters continued to support an older version of Ethereum, splitting the chain into two. This version included the DAO hack and was called Ethereum Classic.

The unplanned hard fork had unintended consequences. Because both chains shared the same transaction history, the hard fork made it possible for replay attacks to occur. A transaction that has been signed and validated on one Ethereum could be “replayed” to nodes on Ethereum Classic. Following the attack, a number of exchanges using pre-fork wallets reported replay attacks. Users would withdraw ETH on an exchange, and split it into an ETH coin and an ETC coin. They would withdraw an unsplit ETH, split it into two coins, and rinse and repeat. Since the withdrawal transaction was “replayed” on both chains, they were basically getting ETC for free.

Replay attacks understandably are damaging to a new coin, as they shake up investor confidence and cause exchanges to suspend withdrawals. To date, Ethereum Classic’s market cap is roughly 5% of Ethereum’s. When Bitcoin Cash hard-forked from Bitcoin in 2017, the developers of Bitcoin Cash had learned their lesson from the DAO hard fork and implemented replay protection on the chain, preventing replay attacks from happening.

Last November, however, Bitcoin Cash went through a hard fork of its own, splitting the coin into Bitcoin Cash (BCH) and Bitcoin Satoshi Vision (BSV). Because both sides considered themselves to be the true successor of Bitcoin, neither chain implemented replay protection.

Failing to add replay protection can significantly slow a forked chain’s growth. Understanding how replay protection works, and how you can protect yourself if developers decline to add such protection, can help keep you safe in a post-fork world.

How replay attacks work

To understand how replay attacks work, we first have to dig into hard forks.

A hard fork is a software upgrade to a currency’s protocol. Nodes running the upgraded software will see blocks produced by the old software as invalid, and vice-versa. Typically, most nodes on the network will quickly adopt the new version of the software to prevent the chain from splitting. However, if some of the nodes run the new software and the other nodes run the old software, the chain will split in two — which is exactly what happened with the DAO hard fork.

Immediately after a blockchain forks, the two resulting chains share the exact same transaction history. Addresses on the new chain end up with the same number of coins that they held on the old chain prior to the split. They don’t just share the same balance: they also share the same private key controlling those addresses. That’s where the opportunity for replay attacks surfaces.

When you send a transaction on a blockchain, that transaction is broadcast to nodes on that network for processing. The nodes will check the transaction to confirm its validity (i.e. that you own the coins in question and have a sufficient balance) and then transfer the coins (i.e. update the ledger) from your wallet to the recipient’s wallet.

Every valid transaction that occurs on a blockchain includes a unique digital signature in the form of a hashcode. In a replay attack, a malicious actor could copy the digital signature from a transaction you executed on one chain and then rebroadcast it to the other chain, and the new chain would accept it as valid.

Here’s an example of how a replay attack might work. Say that BTC is currently valued at $3,000 per coin, and coins on a new fork from Bitcoin are worth $100. You’re holding one BTC and, following the hard fork, one coin from the forked chain.

You decide to spend your new coin from the fork and buy $100 worth of merchandise from a vendor with that attack. Unfortunately, the vendor that you sent the transaction to is crooked: they broadcast that transaction to the Bitcoin network, which confirms it as a legitimate transaction — and you lose one BTC, or $3,000.

Enter Replay Protection

To prevent replay attacks, the developers on one of the two post-fork blockchains can make a slight change to transaction rules. Implementing replay protection on the protocol level requires a hard fork. That means that it’s a lot easier for the new, forked version of the chain to implement replay protection — as it’s already initiating a hard fork.

For example, when Bitcoin Cash forked away from the Bitcoin blockchain, its developers added a special marker (the SIGHASH_FORKID) to the new blockchain’s transactions so that Bitcoin Cash’s digital signatures would no longer be identical to Bitcoin’s signatures.

If an attacker were to copy the signature from a Bitcoin transaction and send it to the Bitcoin Cash nodes, it would be rejected as invalid because it lacked that extra marker. Similarly, signatures with the extra marker would be invalid on the Bitcoin blockchain, which protects against replay attacks in the other direction. Because this form of replay protection prevents replay attacks on both Bitcoin and Bitcoin Cash, it’s called two-way replay protection (or, equivalently, “strong replay protection”).

The decision of whether to include replay protection following a hard fork has important ramifications for both chains.

If two-way replay protection is offered on the protocol level, as with the case with Bitcoin Cash, then exchanges, wallets, and users are able to transact in both coins on the original chain and on the forked chain without fear of replay attacks.

If replay protection isn’t offered at the protocol level, things get more complicated. Services like wallets or exchanges will typically temporarily halt transactions on the new chain until the network stabilizes. If they choose to support the new chain, they’ll have to implement their own replay protection or risk being attacked. This is typically achieved this by mixing in post-fork transaction outputs (UTXOs) with any new transactions or withdrawals.

People using cryptoassets should consider exercising caution with regard to blockchains that do not offer replay protection at the protocol level. Those who keep their funds in a wallet or exchange that supports replay protection should be able to transact as normal — although one may wish to wait for any bugs to be ironed out. If a wallet or exchange doesn’t support replay protection, investors have two options.

1. If they don’t plan on transacting in either of the post-fork cryptoassets, they can leave their funds in a service that doesn’t support replay protection and wait for the service to support it or the protocol to implement it. Replay attacks require a sign transaction, so there isn’t any risk of replay attack if no transactions are initiated.
2. If they do wish to use either post-fork cryptoasset, they can send their holdings to a wallet or exchange that offers a splitting service that they can use to safely separate the original currency from the forked one.

So, why not use replay protection?

The recent Bitcoin Cash / Bitcoin Satoshi Vision hard fork raised some eyebrows when developers on both forks initially refused to implement replay protection (though BSV eventually decided to add protection). They chose to omit replay protection because the two chains were enmeshed in a hashwar: an attempt to determine which was the stronger version of the blockchain by outperforming the other chain. BSV developers claimed that replay protection of the sort offered during the original Bitcoin Cash hard fork would have prevented such a competition.

In effect, BSV and BCH were playing a virtual game of chicken: By refusing to add replay protection, developers left the possibility that one chain died out and the other remained without a split.

As Craig Wright, a leading supporter of Bitcoin SV, tweeted:

Ultimately, the hash war lasted for a week, with neither chain snuffing out the other. Miners were contributing more hash power to both chains than block rewards warranted — losing millions of dollars in the process. Following this, Bitcoin SV announced that it would implement replay protection to the chain, eliminating the possibility of unifying the two chains.

The Consequences

On November 7th, a week before the Bitcoin Cash hard fork, the market cap of Bitcoin Cash was north of ten billion dollars. By November 22th, following the hard fork, the combined market cap of Bitcoin Cash and Bitcoin SV was close to five billion dollars. In a couple of weeks, the combined market cap of the forked currencies was cut in half.

It’s impossible to say how much of this can be tied to the lack of replay protection following the fork — but foregoing replay protection probably didn’t help.

For developers of the primary chain, implementing replay protection is only a necessity if they believe that they’ll lose the hash power war. Implementing replay protection means hard-forking the original chain, which can be risky. If the primary chain can count on more hash power than the forked chain, it’s advantageous to ignore replay protection. That means that they don’t have to hard-fork at all, and there’s a chance that the competing chain subsequently dies out.

Developers who are deliberately trying to create a new, forked currency, as in the case of Bitcoin Cash, should implement replay protection to cleanly split the chain from the original. That helps to shore up investor confidence that the new currency will work as advertised. If the developers of the forked chain believe that they can attract 51% or more of the hash power than the original chain, they might want to consider foregoing replay protection so that the two chains might be unified in the future. But as we saw with Bitcoin SV, doing so can be an extremely risky — and costly — endeavor.

The above references an opinion and is for informational purposes only. It is not intended as and does not constitute investment advice, and is not an offer to buy or sell or a solicitation of an offer to buy or sell any cryptocurrency, security, product, service or investment. Seek a duly licensed professional for investment advice. The information provided here or in any communication containing a link to this site is not intended for distribution to, or use by, any person or entity in any jurisdiction or country where such distribution or use would be contrary to law or regulation or which would subject SFOX, Inc. or its affiliates to any registration requirement within such jurisdiction or country. Neither the information, nor any opinion contained in this site constitutes a solicitation or offer by SFOX, Inc. or its affiliates to buy or sell any cryptocurrencies, securities, futures, options or other financial instruments or provide any investment advice or service.