Lesson 0001: Bitcoin Transaction Lifecycle Overview

Where it happens: The wallet

The wallet selects UTXOs (unspent transaction outputs) that belong to the user, constructs outputs specifying the recipient and amount, computes the fee, and signs each input with the corresponding private key. The result is a serialized transaction — a blob of bytes ready for the network.

Key detail: The signature covers nearly the entire transaction (SIGHASH_ALL by default), making it tamper-proof. If anyone changes an output amount or destination, the signature becomes invalid.

Where it happens: Wallet → First peer node

The wallet sends the serialized transaction to one or more connected full nodes via a tx message (or, if using the inv/getdata flow, the node first announces it has a new transaction via inv, the peer requests it with getdata, and the wallet responds with tx). In practice, wallets often use the simpler tx push: just send the transaction directly.

Key detail: The wallet doesn't need to be a full node. It only needs a connection to at least one peer that accepts and relays transactions. SPV (simplified payment verification) wallets do exactly this.

Where it happens: The peer-to-peer network

Once a full node receives a valid transaction, it relays it to its peers. The standard flow: Node A sends an inv (inventory) message to each peer announcing the txid. Peers that don't already have the transaction respond with getdata. Node A then sends the full tx message. This gossip protocol ensures every full node on the network sees every unconfirmed transaction within seconds.

Key detail: Each node independently validates the transaction before relaying it. If a transaction fails validation (e.g., double-spend, invalid signature, non-standard script), the node rejects it and does not relay it. It may also increase the peer's "ban score" for sending invalid data.

Where it happens: Every full node's memory

After validating a transaction, each full node adds it to its mempool (memory pool) — an in-memory set of unconfirmed transactions eligible for inclusion in the next block. The mempool is not shared or synchronised globally; every node has its own. Transactions stay in the mempool until they are either mined into a block, evicted (if a higher-fee transaction pushes them out), or expire.

Key details:

• Fee competition: Miners select transactions by feerate (satoshis per virtual byte, sat/vB). Higher feerate = higher priority.
• Replace-by-Fee (RBF, BIP 125): A sender can replace their unconfirmed transaction with a new version that pays a higher fee. Useful if the original is stuck.
• Child-Pays-for-Parent (CPFP): If a transaction is stuck with too low a fee, a recipient can create a "child" transaction spending its output with a high fee, incentivizing miners to include both.
• Mempool is ephemeral: If a node restarts, its mempool is wiped. Transactions must be re-broadcast.

Where it happens: The miner (or mining pool operator)

A miner builds a block template — a candidate block — by selecting transactions from their local mempool. This is done via the getblocktemplate RPC (or Stratum protocol in pooled mining). The miner software:

1. Creates the coinbase transaction — the special first transaction that pays the block reward (currently 3.125 BTC) plus accumulated fees to the miner. The coinbase has no inputs; it creates new bitcoin.
2. Selects transactions from the mempool, typically sorted by feerate (highest first), packing them into the block up to the 4 million weight unit limit (roughly 1 vMB for legacy-style transactions, up to ~4 MB with SegWit).
3. Computes the Merkle root — a single 32-byte hash that cryptographically commits to all transactions in the block.
4. Assembles the 80-byte block header: version, previous block hash, Merkle root, timestamp, difficulty target (nBits), and an initial nonce.

Who builds the template? In solo mining, the miner's own bitcoind builds it. In pooled mining, the pool operator builds it and distributes the header (or parts of it) to participating miners via Stratum. The pool decides which transactions to include — individual pool miners have no say.

Where it happens: ASIC hardware

The 80-byte block header is sent to ASIC (Application-Specific Integrated Circuit) miners. The ASIC iterates the nonce field (a 32-bit counter, ~4 billion values) and computes double-SHA256 on the header. If the resulting hash is numerically below the network difficulty target, a valid block is found.

Key details:

• The nonce space alone (2³² ≈ 4.3 billion) is too small for modern difficulty — miners also modify the extra nonce in the coinbase transaction, which changes the Merkle root, effectively giving them a fresh nonce space to search. This is why block templates are continuously refreshed.
• The difficulty target adjusts every 2,016 blocks (~2 weeks) to keep the average block time at 10 minutes.
• At current network hashrate (~700 EH/s), the entire network is searching roughly 7×10²⁰ hashes to find one block — an astronomically large number.

Where it happens: P2P network (in reverse)

When a miner finds a valid block, they broadcast it to their peers. The propagation path mirrors transaction relay: inv → getdata → block (or headers → getdata → block for headers-first nodes, or direct cmpctblock for compact block relay per BIP 152). Every full node that receives the block:

1. Validates the block header: checks PoW, previous block hash, timestamp, difficulty.
2. Validates every transaction: signature checks, no double-spends, scripts execute correctly.
3. Updates its UTXO set: removes spent outputs, adds new unspent outputs.
4. Removes confirmed transactions from its mempool.
5. Relays the block to its own peers.

Compact block relay (BIP 152): Since peers likely already have most transactions in their mempool, the block can be sent as a header + short transaction IDs. Missing transactions are requested separately. This dramatically reduces bandwidth — from ~1.5 MB to ~15 KB in the common case.

Where it happens: Every full node's chain state

Once a block is added to the tip of the chain, the transaction has 1 confirmation. Each subsequent block mined on top adds another confirmation. Most wallets and services consider a transaction "final" after 6 confirmations (a heuristic from Satoshi's whitepaper based on the exponentially decreasing probability of a reorg).

Chain reorganisations (reorgs): If two miners find valid blocks at similar times, the network temporarily has two competing chain tips. Each node follows the one it saw first. When the next block is found, it will build on one of the two tips — the chain with the most accumulated work wins. The other tip becomes a stale block (also called an orphan). Transactions in stale blocks return to the mempool and can be included in future blocks. One-confirmation reorgs happen regularly; deep reorgs (2+ blocks) are rare.