I’ll start out by explaining the history and motivations behind Bitcoin and Bitcoin Cash. What were the problems facing Bitcoin in 2017 and why did some of the community oppose the changes proposed by SegWit2x?
For the technically hungry readers, I’ll add a section at the end that explains the SigHash algorithm used in Bitcoin Cash, which was originally proposed in BIP143 that protects against cross-chain replay attacks.
Bitcoin in 2017
2017 has been a tumultuous year for cryptocurrencies. I had to look up tumultuous to make sure I was using it correctly – “making a loud, confused noise; uproarious” sounds about right.
As the network grows in popularity, transaction speeds (time for a transaction to actually be stored in the blockchain) have become really slow because miners can only serve a certain number of transactions per block. In May, 2017, there were 160,000-some transactions in the backlog.
One group (SegWit2x) decided to make more room in blocks by shuffling how data is stored, and gradually increasing the block size from its current 1MB. Essentially, the beginning of August 2017 would still see 1MB blocks, but without the signatures there would be room more more transactions in each block.
Bitcoin Cash is the other proposal. Bitcoin Cash was created by a team led by ex-Facebook developer Amaury Séchet. The group disagreed with the approach, claiming that it was a “hack”, and was insufficient to battle the longer-term scaling problems that Bitcoin faces.
The two main upgrades offered by Bitcoin Cash include:
- Block Size Increase – Bitcoin cash provides immediate relief by increasing block size by 8x, to 8MB.
- Replay/Wipeout Protection – Ensures that transactions can’t be replayed across chains.
Replay attacks across a forked Bitcoin
A split chain with identities that exist on both leaves room for some interesting attack vectors. Imagine the following scenario:
I want to buy a sandwich for S using Bitcoin Cash. I create a signed and valid transaction from my account A to a sandwich vendor’s account V for the amount of S. It turns out that V is also a participant on the Bitcoin network, so he adds this transaction to the pool of pending transactions, where it is also valid because Bitcoin Cash is a fork of Bitcoin. But on Bitcoin, the unspent transaction output for A has S more BTC than on Bitcoin Cash, so it’ll be valid. V receives 2*S for the sandwich.
Bitcoin Cash offers a mechanism that prevents such attacks from occurring. At a high level, a new SigHash type is introduced where SIGHASH_FORKID is set. This means that each fork will have it’s own identifier. When this bit is not set, fork-specific verification will still proceed as usual, but nodes supporting this feature will perform the extra check.
You can see in the specs for the UAHF (user activated hard fork) specification that Bitcoin Cash nodes must recognize the new Fork ID requirement and “only deem transactions valid” if it’s included during SignatureHash.
This requirement is reflected in the final 2 lines of the suggested UAHF implementation:
What to expect as a Bitcoin Cash user
If you happened to move your BTC from exchanges or 3rd parties, and back onto the blockchain, by block 478558, you now own Bitcoin Cash! Congratulations! You now have more money (Bitcoin Cash is actually decently-priced at the time of writing).
You can make quick, validated transactions without paying higher transaction fees. And you can buy a sandwich knowing that you won’t pay the price of two of them.