 J.J. asks about the Bitcoin Cash hard fork that took place on November 15th. That was the day before yesterday, so it was just two days from the moment of the hard fork. Lots of you had a variety of questions about what this hard fork was, how it happened, what happened exactly. What happened in this particular situation? Bitcoin Cash is a chain that was created on August 1st, 2017. That chain was split off of Bitcoin. That was a fork that happened on August 1st, 2017. On November 15th, 2018, there was a second hard fork. I can give you some of the information of what I think happened from reading about this. I hope this information is as accurate as I can explain it. Plans were made by the developers who were developing the most common Bitcoin Cash node software, which was called Bitcoin ABC. This is the software that most of the Bitcoin Cash network was running. Bitcoin ABC developers decided to add two or three basic features to the Bitcoin Cash chain in a non-backwards-compatible hard fork upgrade. What happens when you do a hard fork update is that the rules of consensus change, so that any clients that do not upgrade to the new rules, are unable to follow the chain. As a result, either all clients have to upgrade, or whichever clients do not upgrade, essentially create a separate fork. Now, in this particular case, two major changes were made. One of them is called OP Datasig Verify. OP Datasig Verify is a script-language opcode that operates inside the Bitcoin script that allows a transaction to validate a signature on an external message. Typically, when you check a signature in Bitcoin script, you can check a signature that is signing the transaction itself, either all of the inputs and outputs, that's called a sig hash all, or some of the inputs, some of the outputs, or just the inputs, or just the outputs. There are a couple of different varieties. But Datasig Verify actually signs a separate message. What that allows you to do is have, as part of a transaction, a message that comes from an external source, perhaps an oracle, that's one of the use cases. An oracle is a service that provides signed data about external events. You could use that for a variety of purposes, including to do various side-chain-type operations, where you have a proof that comes from outside the network. Datasig Verify was one of the upgrades. The other one was a change called CTOR, Canonical Transaction Ordering, C-T-O-R. What Canonical Transaction Ordering does is, it changes the way blocks are built and the consensus rules around blocks, so that the transactions within a block have to have a specific ordering. Now, in classic Bitcoin, if you want, and the way Bitcoin Cash works before this change, transactions are ordered effectively at a random order, with just a few constraints. You can put transactions in a block in any order you want, where the miners can put transactions in a block in any order they want. There is one important constraint, that is, if two transactions depend on each other, meaning they are a chain, whereby the second transaction spends an output created by the first transaction. You can put them in the same block, but they have to be in order, meaning that if you process the transactions one by one, you have to process the parent and then the child. They have to be in that order in the block. That is how you can validate double-spends. C-T-O-R, Canonical Transaction Ordering, is a consensus rule change that requires the transactions within a Bitcoin Cash block to be ordered lexicographically, meaning the alphabetic or alphanumeric order of the transaction ID. They are sorted. What that allows you to do is a certain type of optimization, which is called outputs and inputs, whereby you can go quickly through all of the outputs created in order by all of the transactions, validate those, and then validate all the inputs. By doing that, you can do validation of transactions in the future, potentially in parallel, where you can effectively have separate threads or even perhaps separate processes validating transactions in parallel. This becomes an important optimization when you have large blocks, because the ability to validate transactions fast is critical to being able to validate the block. The bigger the block, the more of a burden that is on validation. C-T-O-R, Canonical Transaction Ordering, was the second change made by Bitcoin ABC. Both of these 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 called Bitcoin SV, or Bitcoin Satoshi's vision. The idea with Bitcoin SV is to introduce a block size increase to 128 megabytes per block, an increase in the limit of script operations that can be included in a transaction to enable more complex contracts or scripts within a transaction, as well as the introduction of about five different new script operands, which were ones that had been previously disabled, that allowed some very interesting complex scripts to be run. These include op-mul, which is for multiplication, as well as op-l-shift and r-shift, which is for left-bit-wise shift and right-bit-wise shift. These types of operations can be used to manipulate numbers in interesting ways, and enable more complex smart contracts. Two different groups within the Bitcoin Cash community proposing two different sets of changes, both of which are not backwards compatible, both of which require changes to the consensus rules, and both of which create new chains. As soon as the fork happens for Bitcoin ABC and Bitcoin SV, essentially the old original Bitcoin Cash chain no longer continues. Nobody is mining the original rules. From that moment on, two groups are mining two different rule sets, creating two competing forks, and those are now effectively called Bitcoin Cash ABC and Bitcoin Cash SV, or Bitcoin SV Satoshi's vision. There was a bit of a hash war, as some commentators noted, where different parts of the Bitcoin Cash ecosystem were trying to dominate the hashing power within the chain, so that the two chains could really proceed in a way that they competed against each other. It was a bit of a competition about who had the most hash power. There was some discussion about, potentially, some attacks against one or the other chain, meaning that groups within the Bitcoin Cash environment could potentially mine competitively to cause a reorganization of the other chain in a competition, essentially. That's what happened. This is a technical explanation of what happened. Of course, as in everything Bitcoin, aside from the technical explanation, there was a boatload of drama and various characters making various threats, leaked emails, forged emails, public accusations, lots of live streams, videos, and podcasts made about all of the personalities and who would dominate over this fight, etc. Mostly worth ignoring. The end result is that, if you had coins on the Bitcoin Cash chain, if you owned Bitcoin Cash in any addresses, then as of the moment after the fork, you effectively now own an equal amount of the Bitcoin Cash ABC and Bitcoin SV coins on the two competing chains. It effectively works like a airdrop or fork, and you can theoretically now split those coins and keep them, sell them, do whatever you want, and you have a bit of on each chain. There was some drama spillover into the Bitcoin blockchain, as well with some price movement, as well as a hash rate declined as different groups that needed all of the hashing power to engage in this competition in Bitcoin Cash withdrew some of their mining from Bitcoin temporarily. Not really a big deal. The mempool is a bit full right now, and the price went down by 10-15%, which in Bitcoin terms is what we call a Wednesday. June asks, what is replay protection? I have no idea what replay protection means. I have heard of 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. So, replay protection is a technique, or a solution to a specific type of problem, which is if you have a fork and you have two independent chains that arise from a fork, and you have a certain value that you had on the parent fork that now has two child's forks, and you want to move the money, but you want to move the money only on one chain. So, for example, in the recent form you had some Bitcoin Cash, and now you have Bitcoin Cash ABC and Bitcoin Cash SV. Now that you have both of these, you essentially have both of these coins controlled by the same keys under the same address, but there are two different chains that track two different ledgers with a common history. So, let's say you wanted to move your Bitcoin ABC to an exchange in order to sell it, and you get an address from the exchange, and you create a transaction, and that transaction you transmit on the Bitcoin ABC blockchain. Great, so the Bitcoin ABC has now moved. Now, if there is no equivalent transaction on Bitcoin SV, then on Bitcoin SV, the money will still be under the old keys, the original address, whereas on Bitcoin ABC, the money will now have moved to a new address, and effectively you've achieved a split. You've managed to split your coins or separate the two histories. But if the transaction that you transmitted on Bitcoin ABC is technically equivalent and has no replay protection, then anyone can take that transaction, receive it on the Bitcoin ABC chain, and then retransmit it on the Bitcoin SV chain, and have a miner include it there. So now effectively your coins moved on both chains, and you wanted to just move one set of coins, but you've now moved on both chains because the transaction was valid under both rule sets, and anyone can retransmit it to the other blockchain. So, how do you stop the transaction from replay? How do you ensure that something you do only happens on one of the two chains, so you can effectively split control of these coins? Once you've done this once, once you've achieved one transaction that is not replayed, then at that point, the coins will be under different addresses, and from that point on, on one chain, they'll already be spent from that address on the other one they won't, so that you can use different keys to control them on different chains, and you've solved the problem. They now have completely different histories. Effectively your coins have forked, but until you do that first, replay protected transaction, you have a problem. So, replay protection can be achieved in a number of different ways. One of the things you can do, for example, is you can use within your transaction some kind of script component that is not compatible on both chains. Let's say, 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 output or input calculation that's used up, Datasig Verify. Now, up Datasig Verify only exists on the Bitcoin ABC fork, and as a result, if you replay that transaction on Bitcoin SV, it would be invalid, because it contains an operand that Bitcoin SV doesn't have. So, you would effectively achieve replay protection by introducing some script operand that only exists on one chain. You could do it the other way, of course. You could include an up-mull or up-l-shift in the script, in one of the insignificant tiny outputs. You could put a tiny amount against it. And as a result, that would ensure that that transaction was only valid on Bitcoin SV, and would be considered invalid on Bitcoin ABC. Once you've done that one transaction, that can only be played on one chain. From that point on, your two sets of coins essentially have divergent history. You can now manipulate them separately with different keys, and not worry about things happening inadvertently. That is what replay protection means. If it's not implemented explicitly by the developers in their forking mechanism, then you have to find a way to do it so that you can do a transaction without that transaction being replayed. By the way, replay protection is not something that only matters in Bitcoin. Replay protection was also needed in the Ethereum classic fork. So, in Ethereum classic fork, the way you do replay protection is through a smart contract that has different behavior on one fork than on the other fork. You send your money to that smart contract, and it behaves differently depending on which fork you're on. Both forks execute the transaction, but they have a different outcome. Effectively, you've split your coins and achieved replay protection. 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 with a smart contract that only works on one chain, not the other, or that works differently on one chain and the other, and again get replay protection. This is a consideration for any blockchain that has these forking characteristics where you can have a hard fork and produce two incompatible chains.