What is Bitcoin Cash?

Introduction

Bitcoin Cash is a proof-of-work blockchain network designed to function as peer-to-peer electronic cash. Its core claim is simple but demanding: digital money should be easy to send directly between people, settle quickly enough for ordinary commerce, and cost little enough that small payments still make sense. That sounds close to Bitcoin’s original promise, so the obvious puzzle is why a separate network exists at all.

The answer is that Bitcoin Cash is not merely “Bitcoin with a different brand.” It exists because part of the Bitcoin community came to believe that the base layer should scale more aggressively for payments, even if that meant changing consensus rules and splitting into a new chain. On August 1, 2017, that disagreement became permanent at block 478558, when Bitcoin Cash split from Bitcoin in a contentious hard fork.

If you keep that design dispute in view, much of Bitcoin Cash becomes easier to understand. Its larger-scale payment ambitions explain its early block-size changes, its focus on low fees, its merchant messaging, its replay protection at the split, and even its newer protocol features such as CashTokens and the Adaptive Block Limit Algorithm (ABLA). The network is trying to answer a particular question: can a proof-of-work chain remain useful as everyday money if it is optimized first for direct on-chain payments?

How does Bitcoin Cash enable peer-to-peer payments without accounts?

At the user level, Bitcoin Cash works like other UTXO-based cryptocurrencies descended from Bitcoin. You hold keys, not an account at a central service. A wallet generates addresses, receives coins, and signs transactions that spend previously received outputs to new recipients. There is no native concept of an account that an operator can freeze or update for you. Control comes from possession of the relevant private keys.

That matters because Bitcoin Cash is aimed at a narrower and more concrete use case than many general-purpose chains. The official description emphasizes fast transactions, low fees, and simple transfers without sign-ups or accounts. In ordinary language, the network is trying to be money first. Not money as a bank database, and not primarily a platform for complex on-chain applications, but money that can move globally with minimal ceremony.

The useful mental model is this: Bitcoin Cash is a shared transaction ledger secured by mining, where anyone can verify the rules and anyone can broadcast a payment, but the protocol is tuned around the economics of spending rather than around preserving very scarce block space. That last clause is the key distinction. Every blockchain has limited throughput. The real question is whether scarcity at the base layer should be treated as a hard design feature or something the protocol should work to relax as demand grows.

Why did Bitcoin Cash fork from Bitcoin in 2017?

Bitcoin Cash came from a disagreement over the best way to scale a cryptocurrency that uses proof-of-work and global node validation. One side of the debate placed more weight on keeping the base layer conservative, with tighter constraints on block growth and more scaling pushed elsewhere. The other side argued that if ordinary payments were priced off the chain by high fees and limited capacity, the system would stop functioning as cash for everyday users.

Bitcoin Cash emerged from that second view. The 2017 split was implemented as a hard fork, meaning the two chains adopted incompatible consensus rules. Once that happened, nodes following Bitcoin Cash rules and nodes following Bitcoin rules no longer agreed on which blocks were valid. That is the mechanism of a chain split: not a political metaphor, but a technical divergence in validity.

The launch details show that this was engineered to be a clean separation rather than an ambiguous coexistence. The UAHF specification set an activation time and required the first fork block to be larger than 1,000,000 bytes. That point matters. If the first Bitcoin Cash block had still fit under Bitcoin’s old 1 MB rule, the split could have been more easily reorganized or confused. By forcing a block that legacy Bitcoin nodes would reject, the fork made the incompatibility explicit and permanent.

The fork also introduced replay protection using SIGHASH_FORKID. Without replay protection, a transaction valid on one chain might also be valid on the other, which can cause users to spend coins unintentionally on both networks after a split. By changing the signature digest rules, Bitcoin Cash made post-fork transactions distinguishable across chains. This is a good example of protocol design under stress: once a community split becomes unavoidable, the next job is to reduce user harm from the split itself.

How does the Bitcoin Cash network validate transactions and blocks?

Underneath the branding and politics, Bitcoin Cash is still recognizably part of the Bitcoin family. It uses SHA-256 proof-of-work, miners produce blocks, nodes validate those blocks against consensus rules, and the chain with the greatest accumulated proof-of-work is treated as authoritative. The monetary policy is also inherited in broad outline: the protocol enforces a capped supply of 21 million coins.

What changes from one Bitcoin-like network to another is not the skeleton but the tuning. Consensus is the part that cannot be hand-waved, because every fully validating node must independently arrive at the same answer to the question, “Is this block valid?” That includes rules for transaction format, signatures, script execution, block construction, proof-of-work targets, and upgrade activation.

A simple payment illustrates the mechanism. Suppose a customer receives coins in a wallet. What they actually receive is an output locked by a script that can be spent only with the correct unlocking data, usually a signature tied to the corresponding private key. When they pay a merchant, the wallet constructs a new transaction that references that earlier output, proves authorization by signing, and creates fresh outputs; one to the merchant, often another back to the sender as change. The transaction is then broadcast to the network. Nodes check that the inputs exist, have not already been spent, satisfy the locking conditions, and obey the consensus rules. Miners can include the transaction in a block, and once the block is accepted by the network, the payment becomes progressively harder to reverse as more proof-of-work accumulates on top of it.

That sounds identical to Bitcoin because, at this level, it largely is. The important difference is what Bitcoin Cash tries to preserve economically. If users regularly compete for very small block space, transaction fees rise and the system becomes less usable for low-value payments. Bitcoin Cash’s design direction has been to make more room for transactions and, more recently, to let capacity adapt more dynamically.

How do block size and fees shape Bitcoin Cash's payment strategy?

The clearest expression of Bitcoin Cash’s philosophy is its treatment of block capacity. At launch, the fork specification required support for substantially larger blocks than Bitcoin’s old 1 MB rule. The logic was straightforward: if blocks can contain more transactions, then users are less likely to bid fees sharply upward just to get included. Low fees are not magic; they are the consequence of trying to keep transaction supply ahead of demand.

That is why Bitcoin Cash markets fees as being very low; often below a penny for a typical transaction. In a payment-oriented system, low fees are not a cosmetic benefit. They are part of the mechanism that makes small-value commerce viable. A network that is cheap only for large transfers is solving a different problem.

But this design choice comes with a real tradeoff. Bigger blocks carry more data, and more data takes longer to propagate across the network. Slower propagation increases the chance that two miners briefly build on different tips, which raises orphan and reorganization risk. This is not a theoretical objection invented by critics; it is a direct engineering tension in all proof-of-work systems. More throughput can pressure decentralization and network stability if hardware, bandwidth, and software efficiency do not keep up.

That tradeoff is easier to see by contrast with a reorg incident on Bitcoin SV, a later chain that split from Bitcoin Cash and pursued even larger blocks more aggressively. Reporting around a 2018 BSV reorganization tied the event to stress-test traffic and large-block propagation delays, illustrating the basic danger: if blocks become large enough relative to network conditions, miners can spend more time disagreeing about the current tip. The example does not prove that every increase in BCH capacity creates the same outcome, but it clarifies the mechanism Bitcoin Cash must continually manage.

Bitcoin Cash’s more recent answer to this problem is ABLA, the Adaptive Block Limit Algorithm, activated in 2024. At a high level, ABLA changes the old idea of a static block ceiling into a dynamic one that can scale with demand. The official description says it allows the network to scale dynamically rather than relying on a permanently fixed cap. The exact economic and security consequences depend on the algorithm’s parameters and implementation details, which are more technical than the overview materials provide, so broad claims should be made carefully. Still, the direction is clear: instead of choosing one permanent capacity number, Bitcoin Cash is trying to make capacity adjustment part of the protocol’s response to actual usage.

How does Bitcoin Cash adjust difficulty after a sudden miner departure?

A proof-of-work chain that has just split faces a special danger: mining power may leave faster than the old difficulty target can adapt. If difficulty remains calibrated for a larger miner set than the new chain actually has, blocks can arrive painfully slowly, degrading usability and confidence. Bitcoin Cash’s 2017 fork specification anticipated exactly this problem.

The initial rules included an emergency-style difficulty relief mechanism. If the chain’s median time past at the tip was at least 12 hours later than the median time past six blocks earlier, the proof-of-work target could be loosened by 25%, which corresponds to roughly a 20% difficulty reduction. In plain language, if block production slowed badly, the chain had a way to recover rather than stalling for long periods.

This detail is easy to overlook, but it reveals something important about network design. Consensus is not just about normal operation; it is also about failure modes. A chain split is a moment when assumptions about hashrate, miner coordination, and software adoption are all unstable. Bitcoin Cash did not merely assert that a new chain would survive. It embedded a mechanism intended to keep blocks coming if the inherited difficulty proved too high for the new miner population.

How does cashaddr and wallet design reduce cross-chain address mistakes?

Chain splits create a practical problem as well as a philosophical one: users can confuse assets and addresses across related networks. Bitcoin Cash addressed this with cashaddr, its preferred address format.

Cashaddr is a base32-encoded address format with a BCH checksum scheme designed to improve error detection and make Bitcoin Cash addresses easier to distinguish from Bitcoin-style legacy formats. A cashaddr address has three pieces: a network prefix such as bitcoincash, a separator :, and a payload that contains the destination data plus checksum. The prefix is not decorative. It identifies the intended network and is part of checksum computation, which helps prevent cross-network confusion.

This is a small-looking design choice with outsized user consequences. A cryptocurrency system can be cryptographically sound and still be hazardous if ordinary users routinely miscopy addresses or send funds to the wrong network format. The cashaddr specification explicitly warns against automatic error correction, because “guessing” a mistyped address could send funds somewhere irreversible. Better detection is safer than confident but silent correction.

The broader point is that protocol usability is part of protocol safety. When Bitcoin Cash says it aims for simple payments, that includes the mundane infrastructure of wallets, QR codes, and address formats, not just mining and script rules.

What are the common real-world uses for Bitcoin Cash?

The network’s official materials emphasize everyday payments and merchant use, and that focus follows directly from the protocol’s design. If transactions are cheap, do not require bank-style accounts, and become final once confirmed, the system is attractive for direct online payments, cross-border transfers, and commerce where card chargebacks are costly. For merchants, no chargebacks is not just a slogan; it is a consequence of how confirmed blockchain transactions work compared with card networks that support payment reversals.

That said, “final” in blockchain systems always needs context. A transaction included in a block is much safer than an unconfirmed one, but proof-of-work finality is probabilistic, not metaphysically absolute. Reorganizations are rare under normal conditions, yet they are part of the model. The practical question is how much confirmation depth is appropriate for the value and risk of a given payment.

Bitcoin Cash has also expanded beyond plain coin transfers. In 2023 it added CashTokens, bringing native support for fungible and non-fungible tokens at the protocol level. This matters because it broadens what can be represented on-chain without relying entirely on external conventions. Earlier token activity on BCH often used higher-layer approaches such as SLP, the Simple Ledger Protocol, which is documented separately in BCH protocol references. CashTokens push some token functionality closer to the base protocol itself.

That does not mean Bitcoin Cash has become a general-purpose smart contract platform in the style of Ethereum. The underlying architecture and programming model remain different. But it does mean the network is not limited to raw coin transfers alone. The through-line is still payment infrastructure: adding native token support can make the chain more useful for assets, applications, and payment-adjacent instruments that benefit from low-fee settlement.

How are Bitcoin Cash upgrades coordinated without a central authority?

Bitcoin Cash is decentralized not only in transaction validation but also in development. The project’s public materials emphasize that multiple independent software implementations contribute to the network, and that no single team controls the protocol. That is an important claim, because in open blockchain systems the code that nodes actually run matters as much as any public narrative about decentralization.

You can see this pluralism in practice. Bitcoin Cash Node (BCHN) is a prominent full-node implementation aimed at miners and operators. bchd is another full-node implementation written in Go, with a modular design that deliberately separates node and wallet functionality. Multiple implementations can reduce single points of failure, create redundancy, and make protocol capture harder.

But plural implementations do not automatically make governance easy. They introduce a coordination problem: if consensus changes require multiple teams to implement compatible behavior, the ecosystem needs processes for proposal writing, review, and activation planning. In Bitcoin Cash, CHIPs (CasH Improvement Proposals) emerged as a community convention for documenting and discussing changes. A CHIP is not an approval stamp by itself. It is a technical document that helps structure debate in a system with no central authority to decree protocol evolution.

This is a subtle but important distinction. In a company, product changes can be mandated. In a permissionless network, changes become real only if enough of the ecosystem (node operators, miners, wallets, exchanges, merchants, and developers) converges on the same rules at the same time. Governance, then, is partly social coordination and partly software release engineering.

What assumptions must hold for Bitcoin Cash's payment-first model to succeed?

Bitcoin Cash makes a coherent argument, but it is still an argument, not a law of nature. Its success depends on several assumptions holding at once.

The first assumption is that on-chain scaling can keep fees low without making validation and propagation costs grow so much that the network centralizes around a smaller set of powerful operators. That balance is the main technical tension in Bitcoin Cash. If capacity remains too tight, the payment vision weakens. If capacity expands carelessly, decentralization and chain stability can weaken instead.

The second assumption is that merchant and consumer demand for direct cryptocurrency payments is strong enough to justify optimizing the base layer around them. This is partly a technical question and partly a market one. A network can be well designed for payments and still face competition from other rails, including stablecoins, custodial apps, and local payment systems that hide blockchain complexity from users.

The third assumption is that the ecosystem can coordinate upgrades without a single authority, while avoiding fragmentation. Bitcoin Cash’s own origin shows that disagreement can produce durable splits. Decentralized development is resilient in one sense, because no single group can dictate outcomes, but it can also be brittle if coordination fails at key moments.

Security assumptions matter too. Bitcoin Cash uses battle-tested SHA-256 proof-of-work, but it also shares that mining algorithm with Bitcoin. In practice, this means hash-power dynamics and miner incentives matter a great deal. The network has also inherited some of the broader operational risks of Bitcoin-like systems, including software vulnerabilities in node implementations. For example, Bitcoin Cash was briefly affected through vulnerable Bitcoin ABC versions in the 2018 INVDoS incident, a peer-to-peer denial-of-service bug involving inv message flooding. That was an implementation-level issue rather than a failure of BCH’s monetary design, but it is a reminder that a blockchain’s safety depends on software quality and operational maintenance, not just consensus theory.

Conclusion

Bitcoin Cash is a proof-of-work blockchain built around a clear thesis: cryptocurrency should work as everyday cash on the base layer. It forked from Bitcoin in 2017 because its supporters thought that preserving cheap, direct payments required different scaling choices, especially around block capacity and fee pressure.

Everything else follows from that thesis. The hard fork, replay protection, low-fee positioning, cashaddr address format, difficulty adjustments, and newer features like CashTokens and ABLA all make more sense once you see the network as an attempt to optimize a Bitcoin-like system for spending rather than for extreme base-layer scarcity. Whether that tradeoff is the right one is still debated. But the idea to remember tomorrow is simple: Bitcoin Cash exists because its community chose to treat on-chain payments as the thing the network should protect first.

How do you buy Bitcoin Cash?

You can buy Bitcoin Cash (BCH) on Cube by funding your account and placing a spot order on the BCH market. Cube supports fiat on-ramps and crypto deposits, and you can choose a market order for immediate execution or a limit order to control price.

1. Deposit fiat via the on-ramp or transfer USDC/BTC into your Cube account.
2. Open the BCH/USDC (or BCH/USD) spot market on Cube.
3. Choose an order type: use a limit order to control executed price or a market order for instant fill.
4. Enter the BCH amount or your spend amount, review estimated fees and the expected fill, then submit the order.