TERM_DEF // TRANSACTION / TRANSACTION_CHAIN
TRANSACTION
CHAIN
CHAIN
transaction-chain/">Transaction Chain. A sequence of unconfirmed transactions where each spends the previous one; CPFP exploits this.
This page sits in the Transaction section — How money moves: inputs, outputs, fees, signatures, sighash flags, and the formats that wrap them. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Transaction section — How money moves: inputs, outputs, fees, signatures, sighash flags, and the formats that wrap them. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_TRANSACTION_CHAIN_IS
Transaction Chain — at a glance
TRANSACTION
Transaction Chain is part of the MEMPOOL sub-family of transaction-level concepts. A sequence of unconfirmed transactions where each spends an output of the previous one — they confirm together or fail together. A sequence of unconfirmed transactions where each spends the previous one; CPFP exploits this.
Why it exists
DESIGN
Users often build dependent transactions (e.g. a Lightning channel open immediately followed by HTLCs, or a CoinJoin followed by spends from each output). The mempool has to track these chains to enforce ancestor/descendant limits and properly evict on full mempool.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
bitcoin-core/">Bitcoin Core enforces: max 25 unconfirmed ancestors, max 25 unconfirmed descendants, max 101 kvB combined size. Beyond those limits the next tx in the chain is rejected from the mempool until the chain shortens via mining.
1. Wallet selects UTXOs whose total value covers the spend amount + estimated fee (coin selection).
2. Wallet builds the transaction body: version, inputs (each with prev txid + vout + sequence), outputs (each with value + scriptPubKey), locktime.
3. Wallet computes the sighash for each input (which parts of the tx the signature commits to — controlled by the SIGHASH flag).
4. Wallet signs each input with the right private key. Witness/scriptSig is populated with the resulting signatures + pubkeys.
5. Tx is broadcast to peers. Mempool propagation: tens of seconds globally.
6. A miner includes it in a block. Confirmation count grows by 1 per block; after ~6 the tx is effectively final.
WORKED_EXAMPLE
Transaction Chain — MEMPOOL
EXAMPLE
Chain example:
tx_1 (parent) → unconfirmed, 100 vB
tx_2 (spends tx_1.vout[0]) → ancestor: tx_1
tx_3 (spends tx_2.vout[0]) → ancestors: tx_1, tx_2
...
tx_25 (spends tx_24.vout[0]) → 24 ancestors
tx_26 (spends tx_25.vout[0]) → REJECTED (exceeds 25-ancestor limit)
Why limit?
• Memory: each pending tx costs ~70 bytes in chainstate accounting.
• Reorg safety: long chains amplify the cost of mempool churn on reorg.
• Pinning protection: long unconfirmed chains make RBF/CPFP harder to coordinate.
KEY_PROPERTIES
ATOMIC
A transaction is either fully accepted into a block or fully rejected. There is no partial spend.
IMMUTABLE INPUTS
A UTXO can only ever be spent once. After that, it is permanently consumed.
NO BALANCES
Bitcoin tracks UTXOs, not balances. Your wallet computes a balance by summing the UTXOs it controls.
IRREVERSIBLE
After ~6 confirmations (~1 hour), reversing the tx would require more proof-of-work than the honest network produces.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- address-reuse/">Address reuse degrades privacy — every reuse links more of your UTXOs together publicly. Modern wallets generate a fresh address per receive.
- Fee estimation matters: under-pay and your tx sits in the mempool for hours; over-pay and you tip the miner more than necessary. Use a fee estimator.
- "Change outputs" must go back to a fresh address you control. A missing change output sends the difference to the miner as fee — a known footgun.
- RBF (Replace-By-Fee) lets you re-broadcast a tx with a higher fee. Useful for stuck txs but means a 0-confirmation tx is never truly final.
RELATED_CONCEPTS
Other terms from Transaction — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Transaction Chain
A sequence of unconfirmed transactions where each spends the previous one; CPFP exploits this.
Transaction (Tx)
A signed payload spending one or more UTXOs and creating new ones; every state change in Bitcoin is a tx.
Raw Transaction
The hex-serialized bytes of a transaction, ready to broadcast or analyze.
Transaction ID (TXID)
wTXID (Witness TXID)
HASH256 of the full transaction including witness data; commits to signatures and used in the witness commitment.
Input
A reference to a previous output being spent, plus the data (scriptSig/witness) authorizing the spend.
Output
An (amount, scriptPubKey) pair created by a transaction; spendable later by a tx whose input references it.
UTXO (Unspent Transaction Output)
An output that hasn't been spent yet; your "balance" is the sum of UTXOs you can sign for.