Bitcoin Cash emerged on August 1, 2017, when incompatible rules produced a separate history after Bitcoin block 478558. Coins recorded before the split existed on both histories, but later transactions and consensus decisions belonged to distinct networks. That shared ancestry explains why BCH supporters talk about continuing an earlier monetary project. It does not mean a payment on one chain appears on the other, or that the assets are interchangeable.

The Bitcoin Cash website presents affordable everyday payments as the project's purpose. This makes block space a question of who can use the system: supporters want ordinary purchases recorded directly on the base chain. A reader can accept that this is the stated objective without accepting the website's strongest claims about reliability or freedom. Those are outcomes to examine through software, operating costs, merchant experience, and the ability to transact during stress.

BCH uses the unspent transaction output model. A transaction consumes earlier outputs and creates new ones with conditions that a later spender must satisfy. Change is normally another output, not a balance adjustment inside a bank account. This distinction matters when reading an explorer: an output is not automatically a purchase, and several addresses can belong to one wallet. Counting addresses or outputs therefore cannot establish the number of independent customers.

The same structure gives wallets flexibility over payment construction. They choose which available outputs to spend, calculate a fee, and return unused value. A recipient needs the correct network and an appropriate address, while the sender must preserve the keys that satisfy the spending conditions. The protocol verifies those conditions; it does not know whether a shop delivered a product. Commercial refunds and disputes remain separate from cryptographic authorization.

A proof-of-work network must adjust mining difficulty as available hash power changes. BCH's ASERT algorithm relates difficulty to the difference between expected and observed block timing, using an exponential adjustment rule. The purpose is a steadier response than abrupt changes at long adjustment boundaries. An algorithm can shape incentives and recovery, but it cannot require miners to supply a particular amount of equipment or electricity.

The August 2020 Bitcoin Cash Node release documented support for the November ASERT activation. That release is useful historical evidence because it identifies actual software and a scheduled consensus change, rather than treating a slogan as an upgrade. It also shows how network governance becomes concrete: developers publish implementations, businesses test them, and miners and node operators choose which rules they will enforce when the activation arrives.

The November 2018 conflict happened within the ecosystem that had already separated from Bitcoin. Competing implementations disagreed over the next BCH rules, including transaction ordering and script changes. Bitcoin SV subsequently followed a separate chain. Calling this the original creation of Bitcoin Cash collapses two events and hides the change in participants. The contemporary r/btc fork discussion records confusion about tickers, exchanges, and which rules businesses would recognize.

A fork thread is evidence of what participants were experiencing, not a neutral referendum on who represented Satoshi Nakamoto. Some commenters treated the split as a contest over authenticity; others concentrated on wallets and operational continuity. The practical lesson is to identify chain history, software, and asset listings separately. Claims to an inherited name do not resolve whether a transaction is valid under either network's present rules.

Bitcoin ABC argued in February 2020 that dependable development funding was necessary to maintain essential infrastructure. Its miner-fund proposal tried to move funding into the rules around block rewards. That was a concrete answer to a recurring open-source problem: users can depend on code without paying the people who maintain it. It was also controversial because a mandatory destination changes who can claim part of the mining subsidy.

Voluntary fundraising offered a competing institution. The Bitcoin Cash Node Flipstarter campaign specified work and requested pledges through an assurance-contract mechanism. Funding could proceed when the target was met rather than requiring every miner to contribute through consensus. This makes deliverables, campaign terms, and later reporting important evidence. A successful fundraiser proves that particular supporters paid for a proposal, not that every holder endorsed the team's authority or priorities.

By August 2020, Bitcoin ABC was explaining a planned November coinbase rule to direct funding to infrastructure. Reading that announcement as a historical position matters: it is not a description of a mandatory fund on today's BCH chain. The later split separated the ABC branch from the chain that retained the BCH identity. Software lineage, ticker continuity, and developers' institutional arguments should be tracked individually.

A November 15, 2020 r/btc discussion celebrated the departure of ABC's leadership. Its antagonistic language shows the strength of opposition among those participants, but cannot establish that every user rejected paid development or trusted the same replacement team. The dispute was about the authority and collection mechanism as much as the need for maintenance. It left voluntary coordination with the continuing problem of paying for work that benefits everyone.

The adaptive block-size proposal argued that repeated manual limit changes were an avoidable coordination burden. Its design responds to observed block usage, allowing capacity to grow when demand persists and to contract when it recedes. The existence of an algorithm does not make bandwidth, validation time, and storage free. Those costs are the reason a growth rule and an effective limit remain relevant even in a network committed to inexpensive payments.

The network's upgrade history records the May 2024 adaptive-limit change alongside later improvements. A larger permitted block is an available ceiling, not evidence that customers filled it. For a payment-focused network, the stronger adoption question is whether inexpensive settlement supports repeated useful exchanges. Spare capacity can be valuable insurance against congestion while still representing demand that has not arrived. Capacity and usage answer different questions.

The CashTokens proposal introduced token primitives that travel with transaction outputs. These primitives give contracts a way to enforce rules involving fungible tokens and nonfungible tokens without adopting an Ethereum-style account system. The proposal discussion includes questions about issuance and how contracts can constrain subsequent transactions. Native enforcement reduces reliance on an indexer's interpretation, but the meaning and value of a particular issued token still depend on its design and issuer.

For example, a token can represent a ticket or a contractual claim only if someone actually honors that interpretation. Consensus can check permitted transfers; it cannot compel admission to a concert or delivery of an off-chain asset. The CashTokens documentation is therefore best read in two layers: what the transaction rules guarantee and what an application promises on top. A programmable payment network gains expressive tools, not automatic legitimacy for everything people mint.

Double-spend proofs are intended to give services evidence of conflicting transactions before confirmation. Their specification discusses timing and supported transaction forms because detection is not universal. A merchant can combine a waiting period, proof monitoring, and purchase limits with an assessment of the goods being sold. The absence of a detected conflict is not the same as a block confirmation, and neither should be described as an unconditional guarantee.

In an October 2021 technical discussion, Max Hastings described why repeated deposits and withdrawals can make some services poor candidates for zero-confirmation acceptance. Respondents explored mitigations rather than treating all payments alike. Buying a low-value physical item and rapidly cycling exchange deposits expose a business to different loss patterns. This is a useful corrective to arguments that an interface showing a fast payment has settled every security question.

The BCH research forum's double-spend-proof discussion connected protocol improvements with end-user guidance. That combination is revealing: deployable code and understandable risk communication have to advance together. A person who cannot review cryptography can still report wallet behavior, challenge an unclear explanation, or ask which transaction forms a service accepts. Such participation is more concrete than identifying with a ticker while assuming someone else will maintain its infrastructure.

Flipstarter's model also makes participation legible. A proposed campaign can describe a finite project, ask for contributions, and let supporters decide whether the public benefit is worth funding. Its assurance mechanism addresses coordination around a funding threshold, not the quality of every proposal. Readers should distinguish the success of the fundraising transaction from later evidence that software shipped, documentation improved, or a merchant service actually gained users.

CashFusion combines participants' inputs and outputs into collaborative transactions intended to make ownership links harder to infer. It is an optional wallet capability layered on BCH, not a change that makes every BCH transfer confidential. Its own FAQ distinguishes this approach from Monero and rejects the idea of an ultimate privacy solution. A reader should preserve that qualification when comparing networks whose default transaction formats reveal different information.

The design also separates coordination from custody: participants sign acceptable transactions themselves, while servers help assemble the group. That reduces a particular custodial risk without proving that endpoint security, subsequent spending, or network metadata can never expose a user. The FAQ discusses Tor and spending practices precisely because transaction construction is only part of privacy. A payment identity can be disclosed outside the blockchain even when an ownership link is difficult to infer on it.

Bitcoin Cash Node's version 28 release implemented the 2025 changes to virtual-machine limits and high-precision arithmetic. Those changes matter for contracts that need larger calculations or more expressive validation. They also demonstrate why a description frozen at the 2017 block-size debate is incomplete: the network has developed a distinct scripting roadmap. Broader computation still requires cost limits and careful application design, rather than allowing arbitrary work to be imposed on every validating node.

Version 29 documents the 2026 additions of pay-to-script, bounded loops, functions, and bitwise operations. The word bounded is consequential: repetition must remain subject to rules a validator can enforce. A new operation can make a contract easier to express without making its economic assumptions sound. Evaluating an application therefore requires both the consensus version it depends on and the business logic that its authors have built using those operations.