Bitcoin Cash keeps Bitcoin's UTXO and Proof-of-Work foundations but makes a different scaling-policy choice: it aims to keep L1 blockspace abundant enough that ordinary payments do not become a permanent auction for every byte. After coordinated increases to 8 MB and then 32 MB, BCH adopted the Adaptive Blocksize Limit Algorithm. Thirty-two megabytes remain the floor, while the ceiling can rise gradually when mined blocks show sustained demand. Difficulty is controlled separately by ASERT with a ten-minute target and a two-day half-life. These mechanisms are best understood together as a system of throughput, mining economics and infrastructure requirements.
BCH retains Bitcoin's UTXO accounting model
A Bitcoin Cash transaction consumes previously created outputs and creates new outputs. There is no single mutable account-balance field; a wallet derives spendable balance from eligible unspent transaction outputs.
An input points to a specific previous output
Each non-coinbase input identifies a previous TXID and output index. That outpoint is an exact coin reference and cannot be spent twice after a valid transaction consumes it.
An output contains value and a spending condition
An output stores a number of satoshis plus a script defining how it may later be spent. The transaction fee is the difference between total input value and total output value.
Change is a new UTXO, not a restored old balance
If a wallet spends a 1-BCH UTXO to pay 0.2 BCH, it normally creates a recipient output and a change output after fees. The original 1-BCH object is no longer unspent.
Coin selection affects fees and privacy
A transaction with many inputs uses more bytes and is generally more expensive at the same feerate. Consolidating many UTXOs can also link address clusters and reduce privacy.
The UTXO set is critical live state for a full node
A node does not need to reread the entire historical chain for every new spend. It maintains the current spendable-output set while validating consensus history to the present tip.
Transaction size matters more than payment value for fee economics
BCH fee economics, like other Bitcoin-family UTXO systems, are driven mainly by serialized size and feerate policy rather than the monetary amount being transferred.
A 1-BCH transfer need not cost more than a 0.01-BCH transfer
If both transactions use similar inputs, outputs and scripts, their byte footprints can be similar. Economic value does not itself make the transaction larger.
Consolidation can be attractive when blockspace is loose
A wallet may combine small UTXOs while fees are low, reducing input count for a future urgent payment. The privacy trade-off is greater linkability.
Large blocks reduce scarcity pressure but do not eliminate fees
Miners still choose transactions and collect fees. BCH policy differs by trying not to make ordinary blockspace scarcity the normal operating condition.
A low user fee is not the same thing as zero infrastructure cost. Miners, nodes, explorers and exchanges still propagate, validate, index and store block data.
Block-limit history: 1 MB → 8 MB → 32 MB
The Bitcoin scaling debate split over how much mass payment demand the base layer should handle directly versus how much should move to upper layers.
BCH launched with an 8-MB limit increase
The August 2017 split introduced consensus rules accepting larger blocks up to 8 MB. This was a protocol divergence, not a wallet-fee preference.
The May 2018 upgrade raised the ceiling to 32 MB
A later coordinated upgrade increased the limit to 32 MB. The accepted ABLA proposal notes that even consensual manual increases carry social and technical coordination costs because the activation must be synchronized.
A fixed limit is also a safety boundary
The ceiling limits more than congestion. It defines a maximum workload that node software, indexers, explorers and exchange backends must be prepared to process and acts as part of the DoS boundary.
Unlimited local block sizes would create consensus risk
If operators independently choose incompatible maximums, a very large block can be accepted by one group and rejected by another. Consensus-safe scaling needs a common deterministic rule.
ABLA makes the block-size limit responsive to mined demand
The Adaptive Blocksize Limit Algorithm was accepted for the May 2024 upgrade. Its purpose is to remove the need for a political and engineering campaign around every future ceiling increase.
Thirty-two megabytes remain the floor
The accepted CHIP preserves the old 32-MB limit as stand-by minimum capacity. Low use does not shrink the network below that base floor.
Control block size follows an EWMA of actual blocks
ABLA uses an exponentially weighted moving-average style control function. Sustained growth in mined block sizes gradually raises the control size.
An elastic buffer provides burst headroom
The control value is supplemented by an elastic buffer. When demand rises sufficiently quickly, the buffer expands so short spikes do not immediately collide with the new ceiling.
Downward adjustment is deliberately slower
The design is asymmetric. The buffer retains memory of recent demand and decays rather than instantly collapsing, reducing oscillation risk.
ABLA does not mean instantaneous unlimited growth
The algorithm reacts to actual mined block sizes under bounded response parameters. Sustained capacity growth requires miners to repeatedly include larger transaction workloads.
An algorithmic limit reduces social coordination cost
Before ABLA, another ceiling increase required agreement on a number, activation mechanism, implementations, testing and coordinated deployment.
Demand becomes part of the feedback loop
When users create more transactions and miners supply more blockspace, ABLA gradually reflects that observed demand in future limits.
One anomalous giant block cannot instantly set a huge new ceiling
The moving-average and bounded-response design smooth short spikes, reducing the ability of a miner or attacker to suddenly impose a radically larger hardware requirement.
The floor preserves ready capacity
Even after extended low use, the network does not shrink to a tiny ceiling. The 32-MB floor represents a baseline infrastructure expectation.
ASERT controls difficulty independently from blockspace demand
ABLA responds to transaction demand. The difficulty algorithm responds to Proof-of-Work production speed. They are separate feedback systems.
The target interval remains 600 seconds
ASERT uses an ideal block time of **600 seconds**, or ten minutes on average.
Mainnet half-life is 172800 seconds
The aserti3-2d parameter is **172800 seconds, or two days**. Roughly two days ahead of its anchor schedule implies a doubling of difficulty; opposite schedule drift reduces difficulty exponentially.
ASERT addressed hashrate oscillations
The earlier 2017 DAA created periodic behavior in which rapid block bursts were followed by long gaps. That harmed confirmation consistency and rewarded opportunistic SHA-256 hash switching.
Difficulty moves smoothly relative to a schedule
ASERT compares height and elapsed time to an anchor trajectory instead of depending only on a short rolling window of recent blocks, improving control-system stability.
Random block intervals still exist
PoW arrivals are statistically noisy even with perfect difficulty. Ten minutes is a long-run target, not a service-level promise for the next block.
SHA-256 links BCH mining economics to BTC
BCH and BTC both use SHA-256 Proof of Work, so the same ASIC class can choose which network to mine.
Miners compare revenue per hash
The decision depends on coin price, subsidy, fees and difficulty. Hashpower can migrate when relative profitability changes.
ASERT reduces the payoff of timing games
The DAA aims to bring block production back toward its ten-minute trajectory smoothly, reducing oscillations that favor strategic switching.
Security budget is not just nominal hashrate
Analysis should consider the amount of compatible SHA-256 hardware elsewhere and the cost of redirecting it. A shared hardware market creates a different threat model from an isolated mining algorithm.
BCH versus BTC is not simply on-chain versus layers
The slogan “BCH is on-chain, BTC is Lightning” is too crude. The engineering disagreement is how much payment demand L1 should absorb directly and how much persistent scarcity is acceptable on the settlement layer.
| Parameter | BCH policy | BTC policy |
|---|---|---|
| Accounting | UTXO | UTXO |
| PoW | SHA-256 | SHA-256 |
| Target interval | ~10 min | ~10 min |
| L1 capacity stance | Larger, adaptive ceiling | More conservative base-layer policy |
| Congestion response | Expand L1 capacity with demand | Fee market plus upper-layer scaling |
| Node trade-off | Higher potential bandwidth/storage workload | More tightly bounded base workload |
More L1 capacity reduces fee pressure all else equal
When available capacity materially exceeds demand, users compete less aggressively on feerate. Long-run miner economics still depend on aggregate fees as subsidy declines.
A smaller L1 makes blockspace scarcer
That can strengthen a fee market and cap base-layer workload, while moving more frequent activity to off-chain or L2 systems.
More L1 throughput raises peripheral infrastructure requirements
The workload affects explorers, wallet backends, exchange indexers, archive services and analytics systems as well as validating nodes.
The scaling trade-off cannot be reduced to “more TPS is always better” or “small blocks always mean more decentralization.” Measure hardware cost, propagation, UTXO growth, fee revenue, actual demand and the number of independent operators that can run the full stack.
Explorer analysis: how to read a BCH transaction
A Bitcoin Cash explorer is best treated as a UTXO graph viewer.
Inputs reveal consumed coins
Inspect the previous TXID, output index and prior value for each input. Multiple inputs often reflect coin selection or consolidation.
Outputs reveal payment and change
One output can be the merchant payment while another is wallet change. Without wallet context, not every output should be interpreted as an independent economic recipient.
Normalize fees by size
Absolute fee is not very informative without bytes. Comparing sat/byte or an equivalent feerate metric is usually more useful.
Block context separates mempool state from settlement
Check height, confirmation depth, block timestamp, block size and current chain tip. An unconfirmed spend and a deeply confirmed UTXO are different risk states.
Scaling economics show up in workload, not marketing TPS
Theoretical maximum throughput depends on transaction size, script mix, validation performance, bandwidth and block interval.
Average transaction size changes practical TPS
Thirty-two megabytes of simple payments contains a different number of transactions from the same bytes filled with heavier scripts or token operations. TPS without a workload definition is a weak metric.
UTXO growth can bottleneck separately from raw historical storage
Millions of new outputs expand live spendable state required for fast validation. Historical block storage and current UTXO state have different operational characteristics.
Propagation affects miner orphan risk
The longer a block takes to propagate and validate, the greater the chance another miner finds a competing block. Efficient propagation reduces but does not erase this trade-off.
Demand should justify infrastructure cost
That is why ABLA uses mined block sizes as feedback: capacity growth is tied to observed use rather than only a political promise of future demand.
The main conclusion
Bitcoin Cash is an experiment in **demand-responsive L1 scaling** built on familiar Bitcoin UTXO and PoW foundations. UTXO defines how coins are spent; transaction bytes define fee workload; SHA-256 miners create blocks; ASERT keeps average production near ten minutes; ABLA regulates maximum block capacity while preserving 32 MB as a stand-by floor.
The main difference from BTC is not cryptography or UTXO accounting but engineering policy around scarce blockspace. BCH prefers to expand accessible L1 capacity with observed demand and accepts a higher potential workload for nodes and services. BTC keeps tighter base-layer capacity and leans more heavily on fee markets and upper layers.
The useful engineering question is not “which block size is correct?” It is **how much L1 demand actually exists, how many independent operators can process the resulting workload, what fee revenue miners receive, and how safely protocol capacity can evolve without social deadlock or consensus instability.**
FAQ
Does Bitcoin Cash still have a fixed 32-MB limit?
Thirty-two megabytes are the floor of the Adaptive Blocksize Limit Algorithm. Since the May 2024 upgrade, the ceiling can rise gradually above that floor under sustained large mined blocks.
What is ASERT?
ASERT is BCH's aserti3-2d difficulty-adjustment algorithm. It uses a 600-second target block interval and a 172800-second half-life, adjusting difficulty according to drift from an anchor schedule.
Why can the same ASIC mine BCH and BTC?
Both networks use SHA-256 Proof of Work. Compatible hardware can switch networks according to relative profitability.
Does the fee depend on how many BCH are transferred?
Not directly. Fee depends primarily on serialized transaction size and feerate. A small payment with many inputs can cost more than a large transfer using one input.
Do larger blocks automatically centralize BCH?
Not automatically, but higher potential throughput raises bandwidth, storage, indexing and validation requirements. Real decentralization should be evaluated through infrastructure cost and independent operator count rather than one ceiling number.
Why have a maximum block size at all?
A deterministic consensus limit sets a predictable upper workload, reduces DoS exposure and prevents nodes with incompatible local limits from disagreeing about valid blocks.
This material is educational and does not constitute financial advice.