Bitcoin Q&A: BCHABC vs. BCHSV hard forks


JJ asks about the Bitcoin Cash (BCH) hard fork that
took place on November 15th, the day before yesterday. We’re just two days [passed] the hard fork. Lots of you had a variety of questions about what
this hard fork was and how exactly it happens. What happened in this particular situation: Bitcoin Cash
is a [forked] 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 [network] hard fork. I can give you some of the information
[based on what I have been] reading about this. I hope this information is accurate as I explain it. 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. 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 were ordered effectively at random, with just a few constraints. Miners can put transactions within a block in any
order you want, with one important constrait. 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 [protect against] 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. 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 [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 previous 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. As soon as the fork happened, [creating] BCHABC and
BCHSV, 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 community 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 [actors] 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 boat load of drama and various characters… making threats and accusations,
leaking emails, forging emails, lots of livestreams and podcasts about these
personalities, and who would dominate [in the end]. Mostly worth ignoring.
The end result is… if you had coins on the old Bitcoin Cash chain, then
you now own an equal amount of BCHABC and BCHSV. [They 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%. You know [by now], in bitcoin terms that is
what we call a Wednesday. Not that exciting. June asks, “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 one chain at a time]. For example, in the recent fork, if you
had some Bitcoin Cash [before the fork], now you have BCHABC / BAB and BCHSV / BSV. Now you have both of these [fork coins]; they are controlled by the same keys, under the
same addresses, but on two different chains… which are tracking two different
ledgers with a common history. If you want to move your BCHABC / BAB to an
exchange in order to sell it, you create a transaction… and transmit it to the BitcoinABC [network]. 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, then [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; 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. For example, 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, [with] another
input or output 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 [for using]
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 [transaction], in one of the insignificant outputs [with] a tiny amount. 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 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]. 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, [they did] replay protection
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. This is a consideration for any blockchain that can have
a hard fork and produce two incompatible chains.

Leave a Reply

Your email address will not be published. Required fields are marked *