Hard forks that result in new cryptocurrencies present unique opportunities and challenges for crypto exchange operators. One challenge that Poloniex faced after the recent Bitcoin Cash hard fork was protecting our customers against replay attacks. Since the development team behind the SV chain opted not to implement replay protection until nearly two weeks after the fork, Poloniex engineers were tasked with devising a solution.

Many in the community were curious as to how Poloniex tackled this particular challenge, so we decided to provide some insight.

What is a replay attack?

While the name implies some kind of malicious act, replay attacks are something that can occur due to the confusion that nodes experience after a hard fork. This confusion can lead to token holders unintentionally sending transactions on one of the new chains, resulting in a loss of funds.

Prior to the hard fork, Bitcoin Cash nodes are all listening for new valid Bitcoin Cash transactions. When a node hears a new transaction, it performs a mathematical test that allows it to verify whether or not the sender is the true owner of the funds. If this mathematical test tells the node that the transaction is valid, it will tell the other nodes in the network and the transaction will eventually get added to the blockchain.

Immediately after the hard fork, some node operators upgraded to the Bitcoin ABC chain and some to the SV chain. A replay attack occurs when a node on one chain hears a transaction intended for the other chain that sounds valid so it communicates it to the rest of the network. For example, Alice sends 1 Bitcoin ABC to Bob and ends up also unintentionally sending 1 Bitcoin SV to Bob as well. Her transaction got “replayed” on the second chain.

Why does this happen?

To understand why this happens, we have to take a look under the hood of a Bitcoin Cash transaction.

If Alice has a wallet with 15 bitcoin cash, she doesn’t own 15 individual BCH - she owns multiple chunks of bitcoin cash, called outputs, that add up to 15 bitcoin cash. For example, Alice’s 15 BCH might be a combination of two outputs: 10 BCH and 5 BCH. Immediately after the Bitcoin Cash hard fork when the blockchain split, Alice now has identical outputs on two different blockchains: 10 BCH-ABC, 5 BCH-ABC and 10 BCH-SV, 5 BCH-SV. The same private key can be used to move all of these outputs.

For simplicity, let’s say Alice wants to send her 5 BCH-ABC to Bob (though transactions typically involve a combination of multiple outputs). Using her private key, she signs a message that says send this specific output of 5 BCH-ABC to Bob. At this point, a BCH-ABC node can perform the mathematical test we mentioned earlier that proves that Alice possessed the private key to send this transaction. The problem arises when a Bitcoin SV node “overhears” this transaction. The Bitcoin SV node can perform the same mathematical test and come to the conclusion that Alice used her private key to send the specific output of 5 BCH SV to Bob.

Alice’s digital signature is valid on both chains. Even though she only intended to send 5 BCH-ABC to Bob, she ends up also sending him the matching output of 5 BCH SV as well.

How to prevent replay attacks

As you can see, replay attacks can occur immediately after a hard fork because everyone has identical outputs on two different chains. A digital signature that moves outputs on one chain is capable of moving matching outputs on the other.

However, as both chains are mined separately after the fork, new unique outputs are introduced via new coinbase rewards. A coinbase award on the ABC chain consists of outputs that do not exist on the SV chain, and vice versa. These post fork outputs are key for preventing replay attacks.

Let’s say for example Jimmy is a Bitcoin Cash miner. If after the fork, Jimmy starts mining BCH-ABC and gets a coinbase reward of newly created BCH-ABC, these would be outputs that don’t exist on the SV chain. If he sent these 5 BCH-ABC to Alice, she could then send them to Bob without fear of a replay attack. If a Bitcoin SV node overheard this transaction, it wouldn’t recognize the outputs Alice is trying to send so no Bitcoin SV would move.

Preventing replay attacks with post-fork outputs

Immediately after the fork, Poloniex began collecting a small set of post-fork outputs, or UXTOs. If Alice were a Poloniex customer and requested to withdraw 5 BCH-ABC, we would mix in at least 1 post-fork output. If a BCH-SV node overheard our transaction, the inclusion of the post-fork output would prevent the SV node from recognizing the transaction. The digital signature would move the specified outputs on the ABC chain and not on the SV chain, because those specific outputs do not all exist on the SV chain.

By employing the method of including 1 post fork output with all BCH-ABC and BCH-SV withdrawals, Poloniex was able to operate with confidence that the exchange and its customers would not be subject to loss of funds resulting from replay attacks.

Article by Connor Dempsey

h/t to Marcus Boorstin who led the engineering effort for the BCH hard fork and who, along with Anders Brownworth, provided the technical insight for this article.

Similar to Notcoin - Blum - Airdrops In 2024

origin »

197 +