A classical network replay attack is when a data transmission across a network is fraudulently or maliciously delayed or repeated. It is a form of a “man in the middle” attack and can be used to replay a message or data transmission in a different context than intended.
Within cryptocurrencies, a replay attack has a particular meaning and is relative to hard forks of different cryptocurrency protocols. Although replay protection is and should be commonplace in the industry, historically it has not always been and future hard forked protocols may choose not to implement it.
Understanding how replay attacks work in relation to cryptocurrencies requires that you first have a basic understanding of how transactions within common cryptocurrency platforms such as Bitcoin work in the first place.
Distributed Ledgers and Hard Forks+
A cryptocurrency such as Bitcoin operates as a global, distributed and digital ledger that exists on all participating nodes. Each full node carries a copy of the entire ledger containing all of the transactions in Bitcoin’s history. The ledger in Bitcoin is also transparent, meaning that all transaction sending and receiving addresses as well as the amounts transferred are visible on the public ledger.
The Bitcoin ledger exists as one universal ledger within the network, meaning all copies are the exact same. The software running the node application is the underlying Bitcoin protocol which also exists as a universal protocol for all the network’s nodes.
Replay attacks become relevant once a hard fork happens within a cryptocurrency protocol. Essentially, the protocol is forked to a new, upgraded version that a new team of developers view as a better iteration of the initial protocol and ledger. Therefore, there is a split between the protocol and the subsequent ledger creating 2 ledgers governed by 2 separate protocols.
The best example of this is with Bitcoin and Bitcoin Cash. On August 1st, 2017, the Bitcoin Cash developers hard forked the Bitcoin protocol. All users who wished to continue on the legacy Bitcoin chain chose not to upgrade their software to the Bitcoin Cash protocol and all users who wanted to join the Bitcoin Cash chain upgraded their software and joined the Bitcoin Cash network. As a result, there remained the original Bitcoin ledger and a new, Bitcoin Cash ledger.
Read our Guide to Bitcoin Cash
Although they share the exact same ledger history leading up to the date of the fork, they exist as two separate chains with different transaction ledgers from that point on. So, you may be asking, what happens to my Bitcoin that I’m holding if there is a hard fork? Well, if you owned Bitcoin prior to the hard fork, then you received an equal amount of Bitcoin Cash as you had initially owned Bitcoin, while retaining your BTC as well. For instance, if Alice owned 5 BTC prior to the hard fork, after the fork she will retain her 5 BTC and receive an additional 5 BCH on the Bitcoin Cash chain. Believe it or not, free money does exist (people said the resulting market values would balance out as a result of the split but that never happened in reality).
What is a Replay Attack?
A replay attack takes advantage of the hard fork and duplication of tokens on the forked chain. The problem for the honest user arises when they want to spend money on one chain but not the other chain. For instance, Alice wants to spend 1 BTC online but does not want to spend 1 BCH at the same time.
The opportunity for a replay attack occurs when Alice spends the 1 BTC from the legacy chain. Because the digital signature attached to the BTC transaction would be the same on the BCH chain, somebody else can duplicate Alice’s signature and include it on a BCH ledger transaction. Basically, somebody else can spend your money on the other chain. However, the exact amount and address used in the transaction needs to be the same for the replay attack to work, otherwise the digital signature would not work.
While it may seem a bizarre form of attack as both the transaction address and amount transferred need to be the same, it can lead to some more complex problems associated with online payments. Therefore, an easy protection against replay attacks is not spending your cryptocurrency that is vulnerable to a replay attack in the first place. It is an inconvenient solution, but works nonetheless. If replay protection is not provided with a cryptocurrency hard fork, most hard wallet services will recommend that you simply not spend any of your coins until the dust has settled and problems with the new fork, including replay protection, have been worked out.
Read our Guide to Bitcoin Forks
Examples and Replay Protection
Replay protection is fairly trivial to implement and at this point should be commonplace and basically a requisite for any hard forked chain. Bitcoin Cash created replay protection for their chain by implementing a unique marker that would allow the Bitcoin Cash nodes to distinguish transactions spent on the legacy Bitcoin chain as independent from the Bitcoin Cash chain.
By identifying the transactions on the BCH chain with a special mark, legacy Bitcoin nodes will similarly reject BCH transactions as invalid. The Bitcoin/Bitcoin Cash split represents a hard fork that implemented replay protection successfully and intentionally prior to the split.
Notably, the once planned and highly controversial SegWit2X Bitcoin hard fork proposal did not include replay protection. Instead, they demanded that the Bitcoin Core team implement replay protection if they thought it was a concern. Obviously, this didn’t turn out well for the SegWit2X team as their planned fork was eventually canceled and they were criticized extensively for their lack of willingness to implement replay protection.
Outside of the strategy employed by Bitcoin Cash to implement replay protection, there are some other strategies directly for users to help mitigate against replay attacks if the cryptocurrency they are using does not provide replay protection.
First, you can use coin mixing services to mix your transactions with a Coinbase transaction which is only valid on one chain and not replayable on a forked chain. However, this strategy requires the use of third party coin mixing services which have their own concerns revolving around their services, so use cautiously.
Second, make sure to use two separate sets of private keys for both chains. Further, you can send your coins to exchanges who have implemented their own splitting services and they will take care of it for you. This happened with the ETH/ETC hard fork where users could use both Shapeshift Splitter and Poloniex to split their coins and provide replay protection.
Conclusion
Replay attacks are really only relevant in distributed blockchain systems when there is a hard fork that does not provide replay protection or lags behind in implementing it after the fork. The concept reached a mainstream boiling point just prior to the proposed SegWit2X hard fork of Bitcoin as they publicly announced they would not be implementing it.
Nowadays, implementing replay protection for a hard fork should be a basic component of the new chain to protect users, otherwise they will not feel secure using the forked network. Whether or not high profile hard forks will continue with the fervor seen at the end of 2017 is yet to be seen, but if they do, you can be sure that the issue of replay attacks will become highly relevant once again.