TERM_DEF // TRANSACTION / REPLAY_ATTACK
REPLAY
ATTACK
ATTACK
Replay Attack. Broadcasting a valid tx from one chain (or context) on another; mitigated by chain-specific sighash data.
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_REPLAY_ATTACK_IS
Replay Attack — at a glance
TRANSACTION
Replay Attack is part of the SECURITY sub-family of transaction-level concepts. Re-broadcasting a transaction signed for one chain on a different chain that shares historical state — only relevant after a fork/">hard fork. Broadcasting a valid tx from one chain (or context) on another; mitigated by chain-specific sighash data.
Why it exists
DESIGN
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Replay protection adds a chain-specific marker to the sighash so a signature on one chain isn't valid on another. BCH used SIGHASH_FORKID (bit 6); BTG used a network magic + sighash variation. Bitcoin's base chain has had no in-protocol replay protection because it's never had a hard fork.
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
Replay Attack — SECURITY
EXAMPLE
Before hard fork:
UTXO X is unspent on chain Bitcoin.
Hard fork at height H:
Both chains inherit UTXO X.
chains diverge after H.
Without replay protection:
Alice signs tx_A spending X (BTC chain)
Mallory copies tx_A and broadcasts on BCH chain
→ X is now spent on BOTH chains, possibly to Mallory's BCH address.
With replay protection (BCH SIGHASH_FORKID):
Alice's BTC sig commits to (sighash | FORKID_FLAG_BTC)
BCH nodes reject the signature → replay impossible.
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
- Replay-attack risk only exists across hard-forked chains that share history. Within Bitcoin itself, signatures are unique to a specific tx and not replayable.
- 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 output/">change output sends the difference to the miner as fee — a known footgun.
RELATED_CONCEPTS
Other terms from Transaction — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Replay Attack
Broadcasting a valid tx from one chain (or context) on another; mitigated by chain-specific sighash data.
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.