The life of a transaction.

A transaction is a data structure with four parts: a version, a list of inputs, a list of outputs, and a locktime. The wallet fills them in locally. No node, no server, and no permission are involved at this point.

The coins are UTXOs: unspent transaction outputs. Each input references one by the id of the transaction that created it and the output index. The input does not carry the amount; the node will look that up in its own UTXO set.

An output is an amount and a locking script: "whoever can satisfy this script may spend it". A change output goes back to the owner's own address. The gap between inputs and outputs is the fee, which no output claims.

Each input gets an unlocking script; for a plain spend that is a signature and the public key. The signature commits to the whole transaction using SIGHASH_ALL, and SIGHASH_FORKID mixes the BCH fork id into the digest so the signature cannot be replayed on BTC or any other fork.

The txid is the double SHA-256 of the serialized transaction, displayed byte-reversed. It is computed, not allocated, which is why explorers on different continents agree on it without talking.

The wallet hands the raw bytes to one or more peers it is connected to, typically over the P2P protocol or through an Electrum-style server that relays on its behalf. Once relayed, the wallet cannot recall or replace the transaction.

A node does not blast the full transaction at every peer. It announces the txid with an inv message; peers that have not seen that id reply with getdata, and only then is the tx sent. This keeps duplicate traffic low as the same transaction arrives from many directions.

Every node validates before relaying, so an invalid transaction dies at the first hop and never floods the network. Relay is best effort: a node may delay or skip an announcement, and a transaction has no guarantee of reaching everyone, only a very high probability.

Propagation across the public network usually completes within a second or two. Merchants rely on this: a zero-confirmation payment seen by many nodes is very hard to quietly replace, and the network will broadcast a double-spend proof if anyone tries.

A full node keeps the entire UTXO set and enforces every consensus rule independently. It does not trust the peer that relayed the transaction. Before the transaction can enter this node's mempool it must pass every check below, in order.

Mempool acceptance combines consensus rules (which every block must obey) with policy rules (which this node applies to unconfirmed transactions). The order shown here is simplified; the checks are real.

Structural checks: the transaction parses, has inputs and outputs, is under the size limit and at or above the minimum size, no output is negative or exceeds 21 million BCH, and no two inputs reference the same outpoint.

The node looks up each outpoint in its UTXO set (and the mempool, for unconfirmed parents). A missing coin means the transaction is orphaned or invalid. This lookup is also where the node learns the input amounts, which it needs for the fee check and for the signature digest.

For every input, the node runs the unlocking script and then the coin's locking script in the Bitcoin Cash script VM, sharing one stack. The trace on the stage is a real evaluation of input 0 by Libauth's implementation of the same VM.

Fee = inputs − outputs. It is never written down; the node computes it from the amounts it looked up in check 2. Policy requires at least the minimum relay fee rate, and mining pools generally accept anything at or above it because blocks have plenty of room.

A conflicting transaction that spends an outpoint already spent by a mempool transaction is rejected. Bitcoin Cash does not implement replace-by-fee, so the first valid spend the node sees is the one it keeps. On detecting the conflict, the node broadcasts a double-spend proof (DSProof) so merchants learn within seconds that someone attempted it.

The transaction is added to this node's mempool and announced to peers. From here on it is a candidate for the next block. There is no fee auction on Bitcoin Cash in normal conditions: blocks are large enough that everything paying the minimum rate gets in.

The mempool is this node's private set of accepted, unconfirmed transactions. Every node keeps its own; they mostly agree but never perfectly. It is bounded in size and transactions expire from it after two weeks if never mined, though on Bitcoin Cash that essentially never happens.

Bitcoin Cash blocks are at least 32 MB and the limit now adjusts upward with sustained demand. Typical blocks are far from full, so there is no bidding war for space and the fee rate has stayed near the one satoshi per byte floor for years. Without replace-by-fee, the first valid spend of a coin is the one that stays.

Block discovery is a memoryless process. The difficulty algorithm (ASERT) steers the long-run average to ten minutes, but individual gaps vary wildly: a couple of seconds, or over an hour. Merchants accept zero-confirmation payments for everyday amounts precisely because the mempool stage is safe enough and the wait is unpredictable.

A new block arrives over the same gossip network the transaction used. Our node removes every transaction the block contains from its mempool, and anything that conflicts with them. In the next room it verifies the block itself before trusting any of that.

The header commits to the previous block hash, the merkle root of every txid in the block, the time, the difficulty target, and the nonce. The node verifies that the header hash is below the target (proof of work), then re-validates every transaction it has not already validated in its mempool. Miners get no special trust.

Canonical Transaction Ordering (CTOR, since November 2018) requires the transactions after the coinbase to be sorted by txid. Any node can then reconstruct the block's order from the set of txids alone, which makes block relay and parallel validation far cheaper.

The coinbase is the block's first transaction and the only one allowed to create value. Its outputs may claim the block subsidy plus the sum of all fees. The subsidy halves every 210,000 blocks; after the April 2024 halving it is 3.125 BCH. Coinbase outputs cannot be spent for 100 blocks.

The merkle root folds every txid pairwise into one 32-byte hash that sits in the header. The header hash is what the miner worked on, so the proof of work covers this transaction indirectly. Our node connects the block to its chain, updates its UTXO set, and relays the block to its peers.

Each block header references the previous block's hash, so the chain is a single linked structure anchored at the genesis block. Rewriting a block means redoing its proof of work and that of every block after it, against the whole network's ongoing hashrate.

Confirmations count the block containing the transaction plus every block built on it. Reorganizations of one or two blocks happen occasionally by accident when two miners find blocks at nearly the same time; the transaction is almost always in both candidates and simply reappears.

Six confirmations is convention, not consensus; exchanges and merchants choose their own thresholds by amount. BCHN additionally finalizes blocks at a depth of ten: it will not accept a competing chain that would reorganize a block more than ten deep, which caps how far back any reorg can reach.

A transaction's outputs become UTXOs the moment the block connects. They are identified by this txid and an index: a44d3a68…:0, …:1 and so on. Any future transaction spending them will reference exactly those outpoints, the way this one referenced its own inputs.