The Blockchain Chief Bitcoin Book / Part V: Applications
Chapter 10

The Complete Transaction Lifecycle

Follow a single bitcoin payment end-to-end, from the moment a user clicks "Send" to the final confirmation buried deep in the blockchain. This chapter ties together every concept from the book.

The Scenario

Alice wants to send 0.05 BTC to Bob. She opens her Bitcoin Core wallet, enters Bob's address (bc1q...), sets the amount, and clicks Send. Here's everything that happens under the hood.

ℹ️ Reading Guide

Each step below references the chapter where that concept is covered in depth. This chapter assumes you've read the preceding chapters; it's the grand finale that connects everything.

Step 1: Creating the Transaction

Covered in Chapter 9: The Wallet

When Alice clicks Send, the wallet's CreateTransaction function takes over:

  1. Decode Bob's address: The bc1q... address is decoded (Bech32) into a scriptPubKey: OP_0 <20-byte-hash>, a P2WPKH output (Chapter 5).
  2. Find Alice's coins: the wallet scans its tracked UTXOs. Alice has three: 0.02 BTC, 0.04 BTC, and 0.1 BTC.
  3. Run coin selection: Branch and Bound, CoinGrinder, Knapsack, and SRD all run. BnB can't find an exact match, so the wallet chooses the 0.02 + 0.04 = 0.06 BTC combination (two inputs).
  4. Build outputs: Two outputs are created:
    • 0.05 BTC → Bob's scriptPubKey
    • 0.0099 BTC → Alice's change address (a fresh address from her key pool)
  5. Calculate fee: with two P2WPKH inputs and two outputs, the estimated virtual size is ~208 vbytes. At ~48 sat/vB, the fee is ~10,000 sats (0.0001 BTC). The math: 0.06 − 0.05 − 0.0001 = 0.0099 change.

Step 2: Signing

Covered in Chapter 3: Cryptography and Chapter 4: Script

For each of Alice's two inputs:

  1. Compute the sighash: hash the transaction with BIP 143 (SegWit) serialization, committing to the input being signed, all outputs, and the spent amount.
  2. Sign with ECDSA: use the private key corresponding to the input's scriptPubKey. The result is a DER-encoded signature + SIGHASH_ALL byte.
  3. Place in witness: since these are P2WPKH inputs, the signature and public key go into the witness field (not scriptSig).
Version2
Marker + Flag0x00 0x01 (SegWit marker)
Input 0Alice's 0.02 UTXO, empty scriptSig
Input 1Alice's 0.04 UTXO, empty scriptSig
Output 00.05 BTC → Bob (P2WPKH)
Output 10.0099 BTC → Alice change (P2WPKH)
Witness 0[signature₀, pubkey₀]
Witness 1[signature₁, pubkey₁]
Locktime0 (or current block height for anti-fee-sniping)

Step 3: Submitting to the Node

Covered in Chapter 6: Validation & Mempool

The signed transaction is submitted via the sendrawtransaction RPC (or internally from the wallet). It's serialized into raw bytes and passed to the validation layer - the exact same path that peer-received transactions take.

Step 4: Mempool Validation

Covered in Chapter 6

AcceptToMemoryPool runs the full gauntlet of checks:

PreChecksNon-empty? Not too big? Not a coinbase? Not already in mempool? No duplicate inputs?
✓
UTXO LookupCheck that both of Alice's input UTXOs exist and are unspent in the current UTXO set
✓
Amount CheckSum of inputs (0.06) ≥ sum of outputs (0.0599). Fee = 0.0001 BTC. ✓
✓
Script VerificationExecute Script for each input, verify Alice's signatures against her public keys
✓
Fee PolicyFee rate (~48 sat/vB) exceeds minimum relay fee (1 sat/vB). ✓
✓
Added to MempoolTransaction enters CTxMemPool, indexed by txid and wtxid

Step 5: Relay Across the Network

Covered in Chapter 8: P2P Networking

Once in Alice's mempool, the transaction is announced to peers:

  1. Queue INV messages: Alice's node schedules INV(wtxid) messages to each connected peer
  2. Poisson delay: each INV is delayed by a random interval (average 2s outbound, 5s inbound) to prevent timing analysis
  3. Peer requests: peers that don't have the tx respond with GETDATA
  4. Send TX: Alice's node sends the full serialized transaction
  5. Propagation: each receiving peer validates (identical ATMP flow) and relays further
  6. Network-wide: within ~5-15 seconds, the transaction reaches most of the ~15,000 reachable nodes

Step 6: Mining into a Block

Covered in Chapter 7: Consensus & Mining

The transaction sits in mempools worldwide until a miner includes it in a block:

  1. Block template: the miner calls getblocktemplate (or equivalent). The algorithm sorts mempool transactions by ancestor fee rate and packs them into a block, respecting the 4 MWU weight limit.
  2. Alice's tx is selected: at ~48 sat/vB, it's well above the mempool minimum and gets included.
  3. Coinbase transaction: the miner creates a coinbase tx claiming the block subsidy (3.125 BTC at current halving) + all transaction fees in the block.
  4. Merkle root: all transaction txids are hashed into a Merkle tree. The root goes into the block header.
  5. Mining loop: the miner increments the nonce (and extranonce) hashing the 80-byte header with SHA-256d until the hash is below the target. At current difficulty, this takes ~10 minutes on average globally.
  6. Block found!: the miner broadcasts the new block.

Step 7: Block Propagation

Covered in Chapter 8

The new block propagates using compact block relay (BIP 152):

  1. The miner's node sends CMPCTBLOCK to its high-bandwidth peers (just the header + short tx IDs)
  2. Receiving nodes reconstruct the full block from their mempools, Alice's tx is already there!
  3. If any transactions are missing, they're requested via GETBLOCKTXN / BLOCKTXN
  4. The block reaches most nodes within 1-3 seconds

Step 8: Block Validation

Covered in Chapter 7

Each receiving node fully validates the block via ProcessNewBlock:

CheckBlockHeader valid? Merkle root correct? Block not too large? Coinbase present?
✓
AcceptBlockConnects to our best header chain? Not a duplicate?
✓
ConnectBlockExecute every transaction's scripts. Update the UTXO set.
✓
UTXO UpdatesAlice's two spent UTXOs are removed. Bob's new UTXO and Alice's change UTXO are added.
✓
Activate Best ChainBlock becomes the new tip. CoinsTip is flushed to disk.

Step 9: Confirmation

The transaction now has 1 confirmation. Here's what happens on both sides:

Bob's Node

Alice's Node

Deeper Confirmations

Each subsequent block adds another confirmation. The transaction becomes exponentially harder to reverse:

1 confirmationIn a block, could theoretically be reversed by a 1-block reorg
3 confirmationsReasonably secure for moderate amounts
6 confirmationsBitcoin's traditional "settled" threshold, ~1 hour
100 confirmationsRequired before coinbase rewards can be spent

End-to-End Summary

Here's the entire lifecycle in one view. Use the interactive animation below to step through each stage:

Or see it all at once:

Wallet: CreateCoin selection → build tx → calculate fee → add change
↓
Wallet: SignECDSA signatures on each input → witness data
↓
Validation: MempoolATMP checks → script verification → accepted into CTxMemPool
↓
Network: RelayINV → GETDATA → TX → propagates to ~15,000 nodes
↓
Mining: Block TemplateTx selected by fee rate → Merkle tree → PoW mining loop
↓
Network: Block RelayCMPCTBLOCK → reconstruct from mempool → 1-3s propagation
↓
Validation: ConnectBlockFull block validation → UTXO set updated → best chain tip
↓
Wallet: Confirmed!Bob sees 0.05 BTC. Alice sees change. 1 confirmation ✓
✅ The Beauty of it All

No central authority was involved. Alice's node talked to Bob's node (indirectly, through the peer-to-peer network). A random miner proved they did real computational work to add the block. Every node independently verified every step. And Bob now has 0.05 BTC that only he can spend.