What you'll learn 👉
Table Of Contents
Bitcoin, for all its positive press, is currently a flawed product which suffers greatly from issues related to scalability and transaction processing speed. Of course, upon noticing a successful but flawed product, many people will flock to try and fix those flaws while gaining their own sweet share of the market. Something like that happened in May of 2017 when the Digital Currency Group published the New York Agreement (NYA). The New York Agreement was signed by a large number of Bitcoin companies and by miners representing over 80% of Bitcoin’s hashpower. This agreement would call for the near-immediate activation of SegWit, technology which separates the transaction data from the signature data. The introduction of SegWit effectively quadrupled the amount of transactions that could fit into a single block and paved the way to introduction of new technologies like the Lightning network.
According to the agreement above, SegWit implementation was to be followed up with a Bitcoin hard fork in November. This fork, called SegWit2x or Bitcoin2x, was supposed to take all the good stuff from the SegWit-improved Bitcoin blockchain and upgrade on it by increasing the block size to 2Mb. Even though this would have hugely helped with Bitcoins scalability issues by doubling the block capacity on the new chain, the project was unceremoniously cancelled in November, citing “lack of consensus” as the main reason. The issue which caused this divide in Bitcoin community was directly related to the Bitcoin2x inability to repel replay attacks and the developers’ lack of plans to add strong replay attack protection onto their blockchain. Replay attacks have been a regular occurrence, not just in crypto world, but in all sorts of internet-related communications for quite a while; now is as good a time as any to explain what those attacks are and how you can protect yourself from them.
Bitcoin Transactions
In order to understand replay attacks, we first have to understand how bitcoin transactions work. They are similar to banking transactions. Bitcoin can be compared to a ledger, except its digital, decentralized and global; Bitcoin transactions are its bank checks. This ledger is stored online and anyone who wants to audit it can do so by downloading an entire copy of the blockchain. This also means that the checks themselves aren’t private. Individual transactions are visible to everyone and anyone can observe and verify them.
This ledger can be upgraded (hard forked). A hard fork creates a new ledger while keeping all the legacy ledger data intact. Once a hard fork is created, the legacy network users have two options: to stay on the old ledger or move onto the new one. If everyone moves, the new ledger becomes global as the old one is pushed aside. If only a portion of users move, we get two ledgers, the legacy ledger and the forked ledger. After the fork happens, new blocks will be found for each blockchain and the chains will start differing from one another.
Replay Attack
A replay attack occurs when a malicious player copies a stream of messages between two parties and replays the stream to one or more of the parties. This problem is a common occurrence in blockchain transactions. Let’s say you own some crypto on the legacy ledger and said ledger was split by a hard fork. You will now, post-split, own the same amount of resources on both ledgers, meaning that your balance in legacy coin stays the same while your balance in the new coin will be equal to your legacy holdings. This can potentially be a problem; if you send a transaction order through one ledger, a malicious player can theoretically intercept your hash function and use it to copy the transaction order and present it on the other ledger.
The person who duplicates your order (presents the copy of your check) on the other ledger is replaying the transaction, making you the victim of a replay attack. For example, if a user wants to spend two Bitcoin on the legacy ledger, a replay attack could cause an equal transaction of two Bitcoin on the forked ledger as well. While the stolen currency wouldn’t necessarily go to the attacker’s wallet address, this vulnerability could empty victims’ wallets on the attacked chain. The attacker usually doesn’t have direct profit in mind, but rather aims to create chaos within the network. The idea is similar to hackers creating viruses for destruction rather than downloading sensitive data from the victims’ computer.
Replay Protection
While replay attacks have happened in the past on the Bitcoin network, they were small scale and never really had any major effects. Similar issues happened on the Ethereum network after it split into two separate ledgers, Ethereum and Ethereum Classic. As an individual user you need to be aware that your funds are vulnerable and that you need to take proper precautions to ensure they are protected. Many individual, user side based concepts have been put out in the ether and they can be used to protect your funds from a replay attack:
- Choose a secure wallet
Choosing a wallet that operates on both networks ensures that users can operate with the full value and capability of their currency. Therefore, the best choice is to use a wallet that provides an easy-to-use platform and operates on both sides of the network. However, while these factors are important, the most important component of a digital wallet is its security standards — specifically regarding the replay attacks that often accompany hard forks like SegWit2x. Services like BTC.com and even the exchange giant Coinbase are creating their wallets with Bitcoin’s hard forks in mind; their products aim to offer a level of protection that will be necessary to fend off any potential replay attacks.
- Mixing your transactions with a Coinbase transaction
Coinbase transactions that are created after the fork are different on each chain. Coinbase transactions are therefore not replayable on any other ledger. If you create a transaction that mixes with a non-replayable transaction, the new transaction will be non-replayable as well. Thus, mixing your transactions with Coinbase transactions makes them non-replayable and has an added bonus of making the transactions that mix with these already mixed transactions non-replayable as well. It is expected that future wallets and exchanges will offer these “mixing” services, both to gain more users by expanding the range of offered services as well as to ensure that non-replayability spreads throughout the entire system.
- NLocktime and doublespend
If one of the blockchains has significantly more frequent blocks than the other, one can create two transactions: One with a nLocktime for the next block on the faster chain, and another that spends at least one of the inputs from the first transaction with a very high fee. First, you broadcast the transaction with the nLocktime which will hopefully get included in the next block on the fast chain. Once it is confirmed, the doublespend is broadcast with a very high fee to the slower chain, hoping that it will get confirmed before the height of the nLocktime of the first transaction is reached. After waiting some more confirmations for safety, the outputs of these two transactions can now be used to create transactions specific to only one chain.
- Doublespending yourself
Create a pair of transactions with different recipient addresses that you own that spend the same funds. Broadcast both at the same time and hope that one gets confirmed on one chain at the same time that the other gets confirmed on the second. If unsuccessful, repeat.
- Two Transactions — Two Fee Settings
It is possible that miners on the ledger blockchain are mining transactions with different fees than on the fork, so you can broadcast a low-fee version of your transaction on the low-fee chain, wait for it to confirm, and then broadcast a higher-fee version on the high-fee chain.
The abovementioned methods require specialized software and a reasonable level of technical knowledge to implement, so they aren’t really suitable for wide application. A good blockchain that hopes to achieve commercial adoption needs to have its own built-in mechanisms which will protect the network from replay attacks. Replay protection is fairly easy to implement but it requires a hard fork of the original blockchain. This is the main reason why Bitcoin doesn’t have it, as implementing this protection would require a fork of the legacy Bitcoin ledger itself which would cause numerous technological issues with Bitcoin-compatible wallets and applications. Therefore, a quality fork needs to implement a form of replay protection, and there are a couple of those out there as well. One of the best techniques to avert replay attacks is to use strong digital signatures with timestamps. Another technique that could be used is to create random session keys which are time bound and process bound. A one-time password for each request also helps in preventing replay attacks and is frequently used in banking operations. Other techniques used against replay attacks include sequencing of messages and non-acceptance of duplicated messages.
A good example of a hard forked ledger dealing with replay attacks happened when Bitcoin Cash split away from the original Bitcoin blockchain. There was a real potential for both networks to become endangered by replay attacks. This danger was removed by creating slightly different transactions (checks) for BCH. Each BCH transaction is tagged with a mark which confirms that the transaction was created specifically for the BCH ledger and not the legacy Bitcoin ledger.
Thanks to this mark, any node now auditing Bitcoin will automatically reject a Bitcoin Cash transaction and vice versa. This special mark is the replay protection.
Bitcoin vs. Bitcoin2x
Even though SegWit2x promised to solve many issues that plague Bitcoin, its developers were heavily against adding replay protection. Instead, they were saying Bitcoin Core itself should add replay protection if it’s that much of a concern. Bitcoin Core developers weren’t against such a fork per-se. What they had issues with was the timeframe they were given, as they needed more than 3 months of time (which is what the timeframe from Bitcoin2x fork announcement to launch was) to prepare for a fork of their own. Many Bitcoin Core developers believed that they would require at least 12 months to complete the full set of adjustments needed for a successful hard fork. Putting the fork out too soon would result in not everyone upgrading from the legacy ledger, which would have resulted in two different ledgers coexisting and resources being wasted.
Among the Core supporters there were many voices who claimed how Bitcoin2x is just an elaborate hijack attempt. Core supporters claimed how switching hashpower to back up non-consensus rules and blockchains is not an ‘upgrade’ but rather a literal definition of a 51% attack. According to the theories, the consortium around Bitcoin2x wanted to break the status quo and convince everyone, both miners and users, to abandon the legacy chain. Calling this “an attack” on Bitcoin might be a bit much as said consortium comprised of many real supporters of Bitcoin, acting in what they believed was good faith. The Bitcoin2x developers finally added support for opt-in replay protection, giving its users option to decide if they want their transaction to be replay protected or not. However, without implementing full replay protection their efforts were bound to put an immense pressure on the legacy ledger. Therefore, this refusal to budge from the SegWit2x/Bitcoin2x team rightfully raises some eyebrows and places blame on their shoulders for the failure of their project.
Conclusion
Every upcoming hard fork represents a serious test for Bitcoin. These forks bring improvements which are necessary to properly adapt the blockchain to commercial use, but they come with risks for the network and its users. The biggest risks come with the replay attacks, which can force a network to face the “boss” monster of the crypto world, the 51% attack. If, like most Bitcoin users, you prefer HODLing rather than spending, replay attacks won’t be affecting you. Keeping your coins in cold storage will be enough to ensure their safety. If on the other hand you enjoy riding the never-ending ride of scalp trading, a Bitcoin fork might cause you some headaches. The best course of action in a hard fork situation will be to wait things out and make sure that the new fork is 100 percent complete and secure. As with everything crypto related, play it safe, be patient and investigate the results of the fork before proceeding to send, receive or act on the Bitcoin network.
