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.