Concerns about replay attacks grow with every eminent hard fork. But what is a replay attack and how does it affect Bitcoin users?
As blockchain developer and Bitcoin enthusiast Andrew DeSantis said on Twitter:
“Replays can happen even with replay protection… they’re related to wallet implementation and withdrawal policies, not just protocol.”
Being a peer-to-peer network, Bitcoin—like other cryptocurrencies—relies on consensus to function. In particular, it uses two forms of consensus: one that verifies transactions and another that governs the rules that guide how to verify the transactions on the public ledger.
Consensus on which transactions to add to the public ledger is formed through an automated algorithmic process known as mining. Nodes in the peer-to-peer network compete to find a solution to a mathematical problem, with the winning node getting the right to add to the public ledger a batch of transactions known as a block. This consensus happens automatically every ten minutes.
Changing the rules
Consensus on the rules that guide mining and other processes on the network, meanwhile, is not automated. Members of the Bitcoin community discuss and have to agree on specific software upgrades that introduce new rules or make changes to old ones. The process of arriving at this type of consensus takes time and it is complicated, especially because members of the community have many conflicting interests.
Nevertheless, changing the rules of the Bitcoin core software is necessary once in a while. For instance, recent pressures to make changes have been occasioned by the growing adoption of Bitcoin, which has put pressure on the network’s capacity to confirm transactions. With the block size capped at 1MB, sending bitcoins is becoming difficult because of delays and high fees.
In August, the community adopted Segregated Witness (SegWit), an upgrade to the core software that reduces the amount of data from each transaction that goes into a block. This creates room for more transactions. The improvement, however, received support from only a portion of the community.
Some users created a new set of rules that instead excluded SegWit and increased the block size to 2MB. This action resulted in a hard fork or branching of the blockchain (public ledger) into two independent chains, the original one and a new one they called Bitcoin Cash.
When a hard fork happens, users end up with coins on both chains. So if you had 2 bitcoins (BTC) before the August hard fork, you ended up with your 2 bitcoins (BTC) plus 2 bitcoin cash (BCH) after the fork.
Replay attacks
A replay attack happens following a fork when you try to send coins on one chain and the network mirrors the action on the other chain. When you send 1 BTC, 1 BCH is also sent.
Before the hard fork, however, the development team behind Bitcoin Cash introduced a protection against replay attacks. They added a line of code to prevent mirroring of transactions. Transactions to send and receive coins on the Bitcoin and Bitcoin Cash networks remain independent from each other, keeping the two chains separate cryptocurrencies.
Before the adoption of SegWit in August, major Bitcoin companies had signed the New York agreement (NYA). This agreement stipulated, as a follow-up scaling solution to SegWit, that an increase in the Bitcoin block from 1MB to 2MB should be implemented on November 18 when the network mines block number 494,784.
Opposition is growing to this planned upgrade, called SegWit2x, threatening another split of the blockchain. With yet another possible hard fork, including the Bitcoin Gold hard fork coming on October 25, concerns of replay attacks are growing. In the case of Bitcoin Gold, some, like the company behind the hardware wallet Trezor, have pointed out that its code is incomplete and lacks replay protection.
To reassure the community, the development team working on the November SegWit2X software upgrade added replay attack protection on 3 October.
As long as you are not using a third-party custodial wallet service, you will automatically receive coins on both chains in the event of a hard fork. Having replay attack protection will make it possible to sell the coins on either chain without concern that your transaction will affect coins on the other chain.
Thus if you only want to support one chain, the coins you want to keep are protected when you sell your coins on the other chain.
