How BitGo Protected Clients During the Bitcoin Cash Hard Fork
Sean Coonce
Dec 4th, 2018/9 minutes to read

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.

Cryptocurrency Forks

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.

The Difference Between a Soft Fork and a Hard Fork

  • Soft Fork: A soft fork is a backwards compatible change in the protocol. This means that nodes that do not upgrade can still validate blocks created by nodes running the newer software. Think of it as a tightening of the consensus rules; new rules are introduced in such a way that old nodes can still participate without being forced to upgrade. Old nodes produce blocks that do not break the new consensus rules, they are simply unaware of them.
  • Hard Fork: A hard fork changes the consensus rules in a way that is non-backwards compatible. Essentially, it’s a change to the consensus rules that prevent non-upgraded nodes from participating in new network activity. Think of these changes as an expansion of the consensus rules; nodes that do not upgrade will not be able to validate blocks created by nodes running newer software.

How BitGo Protected Clients During the Bitcoin Cash Hard Fork 1

  • Contentious Hard Forks: Generally, forks happen across various currencies with little fanfare — they’re simply a set of planned protocol upgrades. Every so often, however, those upgrades can also create a split in community sentiment. When this happens, community support (developers, miners, and users) splits into two distinct groups, creating divergent chains of the currency.

Threats Associated With Hard Forks

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.”

Protecting Oneself Against a Replay Attack

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.

Protecting Our Clients at Scale

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:

  • Suspended BCH indexing: We index each of the various blockchains we support — meaning we parse every new block across each supported chain, enrich the data contained within, and persist each transaction to an internal datastore. During the fork, we temporarily suspended BCH service. This gave us time to monitor both chains (ABC and SV) in order to protect ourselves and our customers against 51% attacks and/or massive, multi-block re-orgs. This also gave us a stable environment to perform the following steps.
  • Get a tainted input: During this suspension in service, we generated a “tainted” input from the BCH ABC chain; a tainted input is an output from a transaction that can only be valid on one side of the fork — either a coinbase transaction from a block above the height of the fork block or a transaction using a new op-code that is only valid on the new chain. In this specific case, we used an output from a transaction that used an op-code only valid on the ABC side of the fork.
  • Fanout the taint: Once we received our tainted input, we used it to create a large number of tainted outputs. The logistics of this can vary, but the general idea is to create enough tainted outputs (on the order of a few thousand) such that they can be used as inputs to taint future BCH transactions to only be valid on the ABC chain.
  • Mix taint into outgoing transactions: Before restarting BCH service, we added new logic that inspects all outgoing BCH ABC transactions. If we detect that the outgoing transaction does not contain any inputs that we explicitly know to have replay protection, we mix in a small, single input from our pool of tainted unspents. This “taints” the transaction — ensuring it is only valid on the ABC chain and prevents it from being replayed on the other side of the fork.

How BitGo Protected Clients During the Bitcoin Cash Hard Fork 2

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.

Jun 12th, 2018
The Building Blocks of Trust
Dec 5th, 2018
BitGo Launches Support for Stellar
Get Started With Us...

For more information on our solutions, start a conversation today!