On November 15th, Bitcoin Cash (BCH) underwent a hard fork after the community was unable to reach consensus around the introduction of new protocol upgrades. As a result, BCH forked into two chains with competing mandates: Bitcoin Cash ABC (ABC) and Bitcoin Cash Satoshi’s Vision (SV).
For BitGo wallet and custody clients, forks require a certain level of protection against both replay and reorg attacks. We supported clients before, during, and after the fork to ensure safekeeping of funds and live-blogged the event to provide transparency and real-time updates to our clients throughout.
With the event behind us, we wanted to provide context around the nuances of cryptocurrency forks as well as BitGo’s strategy to mitigate risks inherent to these types of network changes.
A fork is a change in the protocol governing a cryptocurrency network. This typically means the introduction of new protocol functionality or a change in underlying infrastructure, such as a change in block size.
Reorganization Attacks: When a hard fork takes place, miners must choose which consensus rules to enforce. This choice effectively divides the original network’s hash power into two factions, each with less power than the original network. A decrease in hash power increases each side’s susceptibility to a 51% attack, in which an attacker can produce blocks faster than the rest of the network, thus making a reorg attack possible.
Replay Attack: In the event of a hard fork, a replay attack represents the greatest threat to users because this form of network attack exploits transactions by replicating them on both sides of the fork.
Forks create two chains that, until the time of the fork, shared a common ledger. A replay attack happens when funds on one side of the fork are validly, but unintentionally spent on the other side.
For instance, assume you have 10 pre-fork coins. When the existing chain forks, you continue to hold those 10 coins on the original chain (we’ll call this “Chain A”). When the first block of the new chain is validated, you now hold 10 coins on the new chain¹ (we’ll call this “Chain B”). Let’s say you then broadcast a transaction that spends 5 “Chain A” coins. A replay attack occurs when that same transaction is unintentionally and maliciously replayed on “Chain B.”
Users can protect themselves from a replay attack by “tainting” their transactions with inputs that are only valid on the new chain. This is typically done by using an op-code that is only valid using consensus rules explicitly available on one side of the fork. These types of transactions cannot be replayed on the other side of the fork because they will fail the other side’s consensus rules and thus, will never be included in a block.
Furthermore, any output that comes from a tainted transaction can be safely used in future transactions without being susceptible to being replayed on the other chain. A tainted output only exists on one chain and can never exist on the other chain. Therefore a transaction using this output can never be replayed to the other chain.
Crafting replay-safe transactions can be complex, so BitGo decided to do this for all of our customers — ensuring that all funds spent from BitGo BCH ABC wallets were safe from being replayed on the BCH SV chain.
Here are the steps we took to implement this:
Providing customer support across all security vectors is what defines reliable custody. BitGo is here to help scale your business in times of growth and provide assurance that your assets are safe in times of vulnerability.
Thanks to the following team members for their support before, during, and after the fork:
Under the hood, these coins are unspents from an address valid on both sides of the fork, but they can be spent independently on both chains from this point forward.