Coinbase Deems “Replay Protection” as Essential During Hard Forks to Protect Customer Funds
In a recent Coinbase blog post written by their very own engineer, Breck Stodghill, the need for replay protection – especially during a hard fork – was explained. In particular, Coinbase has implemented replay protection through what they refer to as, “dust mixing”.
This was supposedly done because the firm trusts that it will help protect customer funds from potential replay attacks. Here’s a quick summary of what all of this means and why it is deemed the ideal approach:
Hard Forks With vs Without Replay
For those who are unaware, a hard fork is when a software change results in either an update to a network’s existing rules or the establishment of new rules altogether. An obvious example of this is Bitcoin Cash, which was forked from Bitcoin back in August 2017.
Before said chain split, we only had BTC, but now we have two different chains, with one specifically for BCH.
According to Stodghill, hard forks come in two types: with replay protection and without. The former ensures that “transactions created on one chain are not valid on the other,” adding that the latter poses risks to coin holders because of potential “replay attacks”.
The notion of replay attack implies that transactions that primarily existed on one chain, will reappear on a newer established chain.
Problem(s) With Replay Attacks
As noted above, the main problem with not having replay protection is that a transaction found on one chain will also be present in the new chain. It all starts with nodes. When nodes connect with one another, they acquire knowledge of new transactions.
In order to validate them, mathematical computations are completed and then the transactions are sent to the Mempool. This is the key problem with BSV and BCH, where the former was forked from the latter.
Stodghill gives the following example that explains this and it goes as follows:
“Alice has 1 BCH she wants to send to Bob. Alice signs a transaction sending Bob 1 BCH. Her transaction is broadcast to a BCH node and quickly propagated to all BCH nodes. Due to the fact that BCH and BSV nodes are still able to connect to each other, her transaction is also propagated to at least one BSV node […] and eventually the entire BSV network. […] Alice sent to Bob not only 1 BCH, but also 1 BSV.”
The main problem that could arise from this is that a hacker or tech expert could easily sweep an exchange’s hot wallet clean.
Solution: Dust Mixing To The Rescue
Dust Mixing supposedly allows the team at Coinbase to separate BCH transactions sent by its users to BCH’s chain.
The suggested solution to prevent a transaction from existing on two chains is to ensure that a transaction’s inputs remain in one chain and that the “unspent outputs” are not identical. Here’s how Coinbase prevented replay attacks, like that of Alice and Bob’s example, during the BSV Fork:
- They obtained a BCH Coinbase Reward from a Miner
- The reward was used to create “chain-isolated dust clouds”
- For each “post-fork” transaction, at least one input that was different from the BCH chain was included
- Leftover Coinbase outputs were stored in the hot wallet
- Eventually said outputs become inputs for succeeding transactions for dust outputs
To learn more about the notion of dust mixing and how it prevents a transaction from being validated more than once amidst a hard fork, go to https://blog.coinbase.com/using-dust-mixing-to-protect-customer-funds-during-contentious-hard-forks-97886254c8c2