Bitcoin Cash (BCH) split from Bitcoin on 1 August 2017 because its supporters wanted to scale by making blocks bigger, while Bitcoin went with SegWit and moving small payments to second layers. Everyone who held BTC at the fork got the same amount of BCH. Since then BCH has split again, raised its block size limit to 32 MB and made it adaptive, added native tokens, and kept a simple payment-first design: no SegWit, no Replace-by-Fee, and low fees.
The block size war
In 2010 Satoshi Nakamoto added a 1 MB block size limit as an anti-spam measure. By 2015 blocks were regularly full. Fees rose and confirmation times became unpredictable, and the community split over how to fix it.
| Camp | Proposal | Argument |
|---|---|---|
| "Big blockers" | Raise the limit (Bitcoin XT, Classic, Unlimited) | Bitcoin should be cheap peer-to-peer cash; hardware can handle bigger blocks |
| "Small blockers" (most Bitcoin Core developers) | SegWit soft fork, then second layers such as Lightning | Bigger blocks raise the cost of running a full node, which centralises validation |
SegWit moved signatures into a separate "witness" section and replaced the byte limit with a 4 million weight unit limit, which raised effective capacity to roughly 2 MB under typical use. It also fixed transaction malleability, which Lightning needed. Because it was a soft fork, old nodes kept working.
An industry compromise in May 2017, the New York Agreement ("SegWit2x"), promised SegWit plus a later hard fork to 2 MB. Many big-block supporters didn't trust the second half would ever happen, and they were right: the 2 MB part was called off in November 2017.
The August 2017 fork
A group of developers and miners around the Bitcoin ABC node software went ahead with a hard fork. At block 478,558 the chains shared history; from the next block, BCH nodes accepted blocks up to 8 MB and rejected SegWit. BTC activated SegWit on 24 August 2017.
Because the fork copied the full history, every BTC UTXO existed on both chains. Anyone who controlled their keys at the fork held both coins.
Replay protection done right
The main risk after a split is replay: a transaction signed for one chain is also valid on the other, so sending BTC could accidentally send the same amount of BCH. Bitcoin Cash avoided this by changing how signatures are made. BCH signatures must set a new flag, SIGHASH_FORKID, and sign a different digest (based on the BIP143 algorithm). Bitcoin nodes reject such signatures, and BCH nodes reject Bitcoin's.
SIGHASH_ALL = 0x01
SIGHASH_FORKID = 0x40 # required on Bitcoin Cash
btc_sighash_type = SIGHASH_ALL # 0x01
bch_sighash_type = SIGHASH_ALL | SIGHASH_FORKID # 0x41
Compare the ETH/ETC split in 2016, which had no replay protection at first: users lost funds to replayed transactions until EIP-155 added chain IDs to signatures. The lesson for any contentious fork is that two-way replay protection should exist on day one.
The second split: BCH vs BSV
BCH's early months were rough. An emergency difficulty rule caused hashrate to swing between BTC and BCH, and it was replaced in November 2017. In 2018 the limit went to 32 MB and some disabled opcodes returned.
In November 2018 the BCH community split again. Bitcoin ABC proposed canonical transaction ordering and a new opcode, OP_CHECKDATASIG. A group led by nChain and Craig Wright rejected both and wanted much larger blocks. After a short "hash war", the ABC side kept the BCH name and ticker, and the other chain became Bitcoin SV (BSV). Neither side had added dedicated replay protection, so users had to split their coins carefully, which shows why the 2017 approach mattered.
A smaller split followed in 2020, when Bitcoin ABC tried to direct part of the block reward to its developers. Most of the ecosystem moved to the Bitcoin Cash Node software, and ABC's chain was renamed eCash (XEC).
How Bitcoin Cash differs today
| Bitcoin (BTC) | Bitcoin Cash (BCH) | |
|---|---|---|
| Proof of work | SHA-256d | SHA-256d |
| Block interval | ~10 minutes | ~10 minutes |
| Supply cap | 21 million | 21 million (same schedule) |
| Block limit | 4M weight units | 32 MB floor, adaptive above it |
| SegWit / Taproot | Yes | No |
| Replace-by-Fee | Yes (mempool policy) | No, first-seen rule |
| Signatures | ECDSA, Schnorr via Taproot | ECDSA and Schnorr |
| Native tokens | No (Runes etc. via indexers) | CashTokens (consensus-level) |
| Address format | Base58, bech32/bech32m | CashAddr |
Bigger and adaptive blocks
BCH blocks can hold up to 32 MB. Rather than fight about the number again, BCH adopted an adaptive block size limit algorithm (ABLA) in its 2024 network upgrade: the limit can rise above the 32 MB floor as blocks fill up over time, and fall back toward the floor when demand drops. In practice BCH blocks are usually far below 32 MB, so the limit rarely matters today.
CashTokens
The May 2023 upgrade added CashTokens: fungible tokens and NFTs stored directly on UTXOs and validated by every node, not by an external indexer. Scripts can inspect token amounts and NFT data through introspection opcodes, which makes contract-like "covenants" possible in Bitcoin-style Script. Wallets need to understand tokens; token-aware CashAddr addresses use different prefixes so older wallets don't receive tokens by mistake.
CashAddr
In 2018 BCH switched from Bitcoin's Base58 addresses to CashAddr, which includes a bitcoincash: prefix and a checksum that covers it, so a BCH address can't be confused with a BTC one.
| Starts with | Type |
|---|---|
bitcoincash:q... | Pay to public key hash |
bitcoincash:p... | Pay to script hash |
bitcoincash:z... / bitcoincash:r... | Token-aware versions of the above |
Legacy 1... and 3... addresses still decode to the same scripts on BCH, which is exactly why sending BCH to a BTC address (or the reverse) was a common mistake before CashAddr.
No SegWit, no RBF
BCH fixed third-party malleability through other rule changes instead of SegWit, and it never adopted Replace-by-Fee. Nodes keep the first valid transaction they see for a given coin and ignore later conflicting ones. That supports accepting zero-confirmation payments for small amounts, backed by double-spend proofs that nodes relay when they see a conflict. It's a risk decision, not a guarantee: a miner can still include the conflicting transaction.
Fees and confirmations
With plenty of block space, BCH fees are usually a fraction of a cent, and a transaction paying the minimum fee rate normally confirms in the next block.
Security is a different matter. BCH uses the same SHA-256 hardware as Bitcoin but receives only a small fraction of its hashrate, so renting enough hashpower to reorganise a few blocks costs far less than on BTC. To limit deep reorganisations, BCH nodes by default refuse to reorganise more than 10 blocks deep. For payments that matter:
- Small, low-risk payments: zero-conf or one confirmation is common.
- Larger amounts: wait for several confirmations, and more for exchange-sized sums.
- Exchanges generally set BCH confirmation requirements higher than BTC's for the same value.
Summary
Bitcoin Cash exists because part of the community wanted on-chain scaling with bigger blocks instead of SegWit and second layers. It kept Bitcoin's supply, block time and proof of work, and it has since split off BSV and eCash, added adaptive block sizes, CashTokens and CashAddr, and stuck with first-seen mempool rules. If you work with it, use CashAddr, sign with SIGHASH_FORKID, don't expect SegWit or RBF, and size confirmation requirements to its lower hashrate.
Get the weekly commit
New blockchain deep dives every week.