Whenever a hard fork is standing in front of the door, a term that does not allow anyone to start something: Replay attack. Why this term can still be interesting for SegWit2x is discussed below.
A Ledger for all
The blockchain gives each user an insight into all transactions between all users – at least in the public blockchains. Any user who performs a transaction can look up the data in the blocks of the blockchain. Like a check in a huge checkbook – but everyone can see every check and thus every signature.
Signatures, as we know them from everyday life, are also available on a digital level. Here they are known in a somewhat modified form as “digital signatures”. Creating a digital signature is the equivalent of signing a document, making it “legal”. Signed is not with your own hand, but with the private key, which is thus proof of ownership for your own coins.
No one can know the private key from a digital signature, but anyone can use a mathematical formula to find out whether the signature really comes from the owner.
Bitcoin and Bitcoin Cash
On August 1, many users saw Bitcoin and the Hard Fork. Bitcoin Cash split off from the main network: anyone who owned before the Fork BTC had the same amount as BCH. The blockchain has “forked” and the credit is now available on both crotches.
Since both coins are not so different, a rogue could come here on evil thoughts. If Alice is running a transaction on Bob at BTC, Charlie could watch the whole thing on the blockchain. Charlie sees the digital signature, so to speak, the signed document, and simply inserts it on the BCH blockchain. The result is a transaction that Bob did not want to execute on the BCH blockchain. Someone just “replayed” the whole process, so it’s called replay attack.
In order for replay attacks to fail, you need to install a protection, a replay protection. On the BCH block, this was done with a small modification of the signature generation. Thus, the signatures between BCH and BTC were no longer identical.
What does it mean for SegWit2x?
By the last step – the block increase of SegWit 2x – a hard fork will again be created. Here again we would have two crotches and we would need a replay protection again. The Bitcoin core developer team, however, rejects an implementation of a new replay protection: Too short is the lead time to the fork, you need at least 12 months in advance.
Whether this condition will be problematic will be shown. There are approaches in which Coin mixers make a replay attack impossible afterwards, so solutions seem to be in the room. There is currently no cause for concern. Bitcoin and Bitcoin Cash have shown us that the average user does not change much – but at least you know now when it comes to a replay attack.