A user, ‘JJ’, asked Andreas Antonopoulos about the Bitcoin Cash (BCH) hard fork that took place on November 15th, 2018. Here’s his analysis of the hard fork.
What happened in this particular situation: Bitcoin Cash is a chain that was created on August 1st 2017. That chain split off of Bitcoin, in a fork that happened on August 1st 2017. On November 15th 2018, there was a second hard fork.
Changes in the Bitcoin Cash Node Software, BitcoinABC
Plans were made by the developers of the most common Bitcoin Cash node software, BitcoinABC. This is the software that most of the Bitcoin Cash network was running on. BitcoinABC developers decided to add two or three features in a non-backwards-compatible hard fork.
What happens when you do a hard fork update is – the rules of consensus change in such a way that any clients that do not upgrade to the new rules are unable to follow the chain. As a result, all clients have to upgrade. Clients which do not upgrade essentially create a separate fork. In this particular case, two major changes were made.
One of them is called OP_DATASIGVERIFY
OP_DATASIGVERIFY is a script language opcode that allows a transaction to validate a signature on an external message. Typically, when you check signatures in Bitcoin script, you check a signature of the transaction itself; either all of the inputs and outputs with SIGHASH_ALL, some inputs and outputs, or just the inputs or outputs. There are a couple of different varieties. DATASIGVERIFY actually signs a separate message, that allows you to have a message as part of a transaction. [The message] comes from an external source, perhaps an oracle providing signed data about external events. So you could use that for a variety of purposes, including various sidechain-type operations – where you have a proof that comes from outside the network. DATASIGVERIFY was one of the upgrades.
The other was called Canonical Transaction Ordering (CTOR)
Canonical transaction ordering changes the consensus rules around the way blocks are built. The transactions within these blocks must have a specific ordering. In the way Bitcoin Cash worked before this change, transactions are ordered effectively at random with just a few constraints. Miners can put transactions within a block in any order you want, with one important constraint. If a transaction depends on another, whereby it spends outputs created by the first transaction – you can put them in the same block, but they have to be in order. If you process the transactions one by one, you have to process the parent and then the child. They must be in that order in the block. That is how you can prevent double-spends.
Canonical transaction ordering is a consensus rule change that requires transactions within a BCH block to be ordered lexicographically, meaning the alphanumeric order of the transaction ID. That allows you to do a certain type of optimization called “outputs, then inputs,” whereby you can go quickly through all of the outputs created by all of the transactions, validate those, and then validate all the inputs. In the future, you could potentially do transaction validation in parallel, where you can effectively have separate threads or perhaps processes validating transactions. This becomes an important optimization when you have large blocks because the ability to validate transactions quickly is critical to validating the block. The bigger the block, the more of a burden there is on validation. Canonical transaction ordering (CTOR) was the second change made by BitcoinABC. Both of these changes were not backwards-compatible. However, not everyone in the Bitcoin Cash environment agreed with these two changes.
Bitcoin Satoshi’s Vision (BCHSV)
Another group of developers decided that this was not a good direction to take the Bitcoin Cash blockchain. They proposed another set of changes in the form of BSV or “Bitcoin Satoshi’s Vision.” The idea with BSV was to introduce a block size increase to 128 megabytes – an increase in the number of script operations (opcodes) that can be included in a transaction, to enable complex contracts, or scripts, as well as introducing variations of five script operands that were previously disabled. These include OP_MUL (for multiplication), OP_LSHIFT (left-shift), OP_RSHIFT (right-shift), and OP_INVERT. These types of operations can be used to manipulate numbers.
So, there were two different groups within the Bitcoin Cash community proposing different sets of changes; both of which are not backwards-compatible, require changes to the consensus rules and create new chains.
Bitcoin ABC (BCHABC) vs Bitcoin Satoshi’s Vision (BCHSV)
As soon as the fork happened, creating BitcoinABC and BitcoinSV – the old Bitcoin Cash chain no longer continues. Nobody is mining with the original rules now. Two groups are mining different rule sets, creating two competing forks, which are now effectively called BCHABC and BCHSV. There was a hash war, as some commentators noted, where different parts of the Bitcoin Cash ecosystem were trying to dominate the chain with hashing power. But the two chains proceeded by competing against each other, about who had the most hash power. There was some discussion about some potential attacks against one or the other chain, meaning groups within the Bitcoin Cash environment could potentially mine competitively in order to cause a re-organisation of the other chain. That is what happened.
This is the technical explanation of what happened, of course.
Aside from the technical explanation, there was a boatload of drama – and various characters making threats and accusations, leaking emails, forging emails, lots of live streams and podcasts about these personalities, and who would dominate in the end – mostly worth ignoring. The end result is that if you had coins on the old Bitcoin Cash chain, you now own an equal amount of BCHABC and BCHSV – that are on two competing chains. It effectively works like an airdrop. You can theoretically split those coins and keep them, have a bit of each, sell them, or do whatever you want.
Some drama spilled over into the Bitcoin blockchain as well, with some price and hash rate declines.
Different groups that needed hash power to engage in this BCH competition withdrew some of their mining from Bitcoin temporarily, but it was not a big deal. The mempool is a bit full right now and the price went down by 10 – 15%.
What is Replay Protection?
In bitcoin terms that is what we call a Wednesday… not that exciting.
“What is replay protection?”
I have no idea what ‘replay protection’ means. I have heard this terminology being thrown around during debates about Bitcoin forks.
“Could you please help me understand why replay protection is important, and relate it to an example? Thank you.”
Replay protection is a technique or solution to a specific type of problem when you have a fork. When you have two independent chains that arise from a fork, where you had value on the parent chain that is now on each of the two child fork chains, you may want to move the money. But you want to move the money only on one chain (or at least only on one chain at a time).
For example, in the recent fork, if you had some Bitcoin Cash before the fork, now you have BCHABC and BCHSV. You have both of these fork coins; where they are controlled by the same keys, under the same addresses, but on two different chains that track two different ledgers with a common history. If you want to move your BCHABC to an exchange in order to sell it, you create a transaction and transmit it on the BitcoinABC blockchain.
Great, the BCHABC has now moved. If there is no equivalent transaction on BCHSV, then those coins will still be under the old keys and addresses. Whereas, on BitcoinABC, they will have moved to a new address. Effectively you’ve achieved a split of your coins, to separate the two histories.
But if your transaction on BitcoinABC is technically equivalent to one that could occur on the SV chain, and there is no replay protection – it can be re-transmitted and included in a block on the SV chain. Effectively, your coins moved on both chains. You wanted to just move one set of coins, but they moved on both chains because the transaction was valid under both rule sets. Anyone can re-transmit it to the other blockchain.
How do you stop the transaction from replaying? How do you ensure that a transaction only happens on one chain, so you can split control of the coins?
Once you’ve achieved one transaction that is not replayed, the coins will be under different addresses. From that point, they will already be spent on one chain; where on the other one, they won’t. You can use different keys to control them on different chains, and you’ve solved the problem. They now have different recent histories. Your coins have forked. But until you do that first replay-protected transaction, you have a problem.
Replay protection can be achieved in a number of different ways. You can use, within your transaction, some kind of script component that is not compatible on both chains. For example, in the current Bitcoin Cash fork, you could have, as part of your transaction, some inputs and outputs that move your coins and another input or output calculation that used OP_DATASIGVERIFY.
OP_DATASIGVERIFY only exists on the BitcoinABC fork. As a result, if you replay that transaction to the SV fork, it would be invalid because it contains an operand SV doesn’t have. You would achieve replay protection by introducing some script operand that only exists on one chain.
You could do it the other way, of course, by including an OP_MUL or OP_LSHIFT in the script – in one of the insignificant outputs with a tiny amount against it. As a result, that would ensure the transaction was only valid on SV, and be considered invalid on BitcoinABC. Once you have done that transaction which can only be played on one chain, your coins have a divergent history. You can manipulate them separately with different keys and not worry about things happening inadvertently. That is what replay protection means. If it is not implemented explicitly by the developers in their forking mechanism, then you have to find a way to do it yourself.
Not only confined to Bitcoin
By the way, the replay protection is not something that only matters in Bitcoin. Replay protection was also needed in the Ethereum and Ethereum Classic fork. In the Ethereum Classic fork, replay protection was done through a smart contract that has different behaviour on one fork than on the other fork.
If you send your money to that smart contract, it behaves differently depending on which chain you execute the transaction. They have a different outcome. Effectively you have split your coins and achieved replay protection.
It’s the same thing that we talked about before, where you have a script that only works on one chain and doesn’t work on the other; you can do that with a smart contract that only works on one chain. Or that works differently on one chain, and the other – and again, get replay protection. This is a consideration for any blockchain that can have a hard fork and produce two incompatible chains.
To watch Andreas talk about the Bitcoin Cash Hard Fork, click here.