Bitcoin transactions do not confirm instantly. Between broadcast and inclusion in a block, a transaction exists in the mempool—a node's set of unconfirmed transactions—where it competes with every other transaction for limited block space. The currency of this competition is fees: miners select the transactions that pay the highest fee per unit of weight.
But what happens when you set the fee too low? Your transaction languishes in the mempool, unconfirmed for hours or days. Bitcoin provides two complementary mechanisms for adjusting fees after broadcast:
Both are relay policy, not consensus—nodes choose whether to relay replacements, and miners choose whether to mine them. But the incentive structure makes both robust in practice: miners prefer more fees, and both RBF and CPFP increase the total fee available.
As we learned in Chapter 16, the nSequence field serves multiple roles. For RBF, the relevant rule is simple:
| nSequence value | RBF status |
|---|---|
\(\geq\) 0xFFFFFFFE | Not replaceable (opted out) |
\(<\) 0xFFFFFFFE | Replaceable (opted in) |
A transaction is considered replaceable if any of its inputs has \(\texttt{nSequence} < \texttt{0xFFFFFFFE}\). This is the opt-in signal defined by BIP 125†.
Most modern wallets set \(\texttt{nSequence} = \texttt{0xFFFFFFFD}\) by default, which simultaneously:
When bit 31 of nSequence is set, BIP 68 is inactive for that input: the lower bits are not interpreted as a relative timelock, even if they would otherwise look like one. This is how 0xFFFFFFFD can simultaneously signal RBF and enforce nLockTime while imposing no relative delay.
When a node receives a replacement transaction, it must satisfy five rules to be accepted into the mempool:
Rule 2 prevents a subtle attack. Without it, an attacker could create a low-fee transaction, then "replace" it with a new transaction that adds unconfirmed inputs from other people's transactions. This would let the attacker "pin" other users' transactions by making them part of a replacement chain they didn't consent to. By requiring that unconfirmed inputs come only from the original transactions, BIP 125 ensures the replacer can only affect their own transaction graph.
BIP 125 defined opt-in RBF: only transactions that explicitly signal replaceability can be replaced. But this created a cat-and-mouse game: some services treated unconfirmed, non-signaling transactions as "safe," which was never guaranteed by the protocol.
The evolution toward full RBF proceeded in stages:
| Version | Change |
|---|---|
| Core 0.12.0 (Feb 2016) | Opt-in RBF relay and wallet support† |
| Core 24.0 (Nov 2022) | -mempoolfullrbf option added (default off)† |
| Core 28.0 (Oct 2024) | -mempoolfullrbf default changed to 1 (on)† |
With full RBF, any unconfirmed transaction can be replaced by a higher-fee alternative—regardless of nSequence signaling. The opt-in signal remains useful as a hint to wallets and recipients, but it is no longer the sole gatekeeper for replacement at the relay layer.
RBF replacement rules are enforced by individual nodes' mempool policies, not by the consensus layer. A miner can include any valid transaction in a block, even one that "violates" BIP 125 rules. In practice, miners follow standard relay policy because they receive most transactions through the P2P network. But the distinction matters: consensus rules are inviolable; relay policies are configurable.
Every example in §17.2 (RBF) and §17.3 (CPFP) refers back to this same parent transaction. Establishing it once means the math in each subsection reconciles to concrete bytes, not arbitrary numbers.
| Field | Value |
|---|---|
| Type | P2WPKH (native SegWit, 1-of-1) |
| Inputs | 1 × P2WPKH spending one of Alice's UTXOs (~50,500 sats) |
| Outputs | 2 — pays Bob 50,000 sats; Alice keeps the change |
nSequence | 0xFFFFFFFD (signals RBF + enables nLockTime) |
| Total fee | 500 sats |
| vsize | 141 vB |
| Feerate | 500 ÷ 141 ≈ 3.55 sat/vB (rounded to 3.5 in prose) |
Where 141 vB comes from — the per-component weight breakdown (recall §8.6):
| Component | Bytes | Weight (×4 non-witness, ×1 witness) |
|---|---|---|
| Version (4) + counts (2) + locktime (4) | 10 | 40 WU |
| 1 input: 32 prev txid + 4 vout + 1 scriptSig length (=0) + 4 sequence | 41 | 164 WU |
| 2 outputs: each 8 value + 1 length + 22-byte P2WPKH spk | 62 | 248 WU |
| SegWit marker + flag | 2 | 2 WU |
| Witness: 1 stack count + (1+71) sig + (1+33) pubkey | 107 | 107 WU |
| Total | 222 raw | 561 WU |
| vsize = ⌈weight ÷ 4⌉ | 141 vB |
The RBF replacement (§17.2.1 below) is the same shape — same inputs, same outputs (possibly different addresses), so it lands at ~141 vB as well, only with a higher fee. The CPFP child (§17.3.1) is a new transaction spending Bob's 50,000-sat P2WPKH output to a payment output plus change (two outputs), also ~141 vB by the same accounting.
Now Alice's transaction is in the mempool, but the mempool is congested, and at 3.55 sat/vB it is not confirming.
To replace it, Alice creates a new transaction that:
The replacement satisfies BIP 125 because:
When the replacement enters the mempool, the original transaction is evicted—it ceases to exist in that node's mempool. The original's txid is gone; the replacement has a completely new txid.
A replacement transaction must spend at least one of the same inputs, but otherwise it can differ in almost any way:
| Can change | Cannot change |
|---|---|
| Fee amount | Must spend \(\geq 1\) same input |
| Output amounts | Must pay higher absolute fee |
| Output addresses | Must not add unconfirmed inputs |
| Number of outputs | Must not evict \(> 100\) txs |
| Change address |
This flexibility means RBF can be used not just for fee bumping, but also for transaction batching (adding more recipients to a pending payment) or cancellation (replacing the transaction with one that pays back to yourself).
RBF requires the sender to act: only someone who controls the inputs can create a replacement. But what if the recipient needs to accelerate the transaction? The sender may be unavailable, uncooperative, or the transaction may not signal RBF.
CPFP solves this from the recipient's side.
If Alice's transaction to Bob is stuck at 3 sat/vB (the specimen's 3.55, rounded down), Bob can spend his unconfirmed output in a new "child" transaction with a very high fee. A rational miner evaluating the child transaction realizes it cannot be mined without its parent (since it spends an unconfirmed output). The miner therefore evaluates the package feerate:
\[ \text{Package feerate} = \dfrac{\text{parent fee} + \text{child fee}}{\text{parent vsize} + \text{child vsize}} \]
\[ \dfrac{500 + 5{,}000}{141 + 141} = \dfrac{5{,}500}{282} \approx 19.5 \text{ sat/vB} \]
If 19.5 sat/vB clears the current block, both transactions confirm together.
| RBF | CPFP | |
|---|---|---|
| Who acts? | Sender (input controller) | Recipient (output spender) |
| Mechanism | Replace the original tx | Add a high-fee child tx |
| Signaling | nSequence \(<\) 0xFFFFFFFE | No signal needed |
| Block space | Same or less (replaces original) | More (adds a second tx) |
| Fee efficiency | Higher (no extra tx) | Lower (pays for two txs) |
| Confirmation | Only replacement confirms | Both parent and child confirm |
When both options are available, RBF is more fee-efficient because it does not consume additional block space. CPFP is essential when the sender cannot or will not cooperate.
To prevent mempool resource exhaustion, Bitcoin Core enforces policy limits on unconfirmed transaction chains. These are defaults in Bitcoin Core; individual nodes may configure different values and they are not consensus rules:
| Limit | Default value |
|---|---|
| Maximum ancestor count | 25 transactions |
| Maximum ancestor size | 101,000 vB |
| Maximum descendant count | 25 transactions |
| Maximum descendant size | 101,000 vB |
These limits mean a CPFP chain cannot grow indefinitely. If a transaction already has 24 unconfirmed ancestors, no further children can be created until some ancestors confirm.
Bitcoin Core includes a CPFP carve-out rule: one additional child transaction is allowed beyond the descendant limit if it has no more than one unconfirmed ancestor. This exception exists specifically for Lightning Network commitment transactions, where both channel partners need the ability to fee-bump their commitment via CPFP, even if the descendant limit is already reached.
Bitcoin Core 28.0 introduced Topologically Restricted Until Confirmation (TRUC) transactions†, also known as "v3 transactions" because they use \(\texttt{nVersion} = 3\).
TRUC transactions impose strict topology rules:
These restrictions make fee-bumping via CPFP simple and predictable: there is always room for exactly one child, and that child can always be replaced with a higher-fee version. TRUC transactions are designed for protocols like Lightning, where reliable fee-bumping is critical for security.
Alongside TRUC, Bitcoin Core 28.0 introduced Pay-to-Anchor (P2A)—a new output type designed specifically for fee-bumping:
OP_1 OP_PUSHBYTES_2 4e73
This is a SegWit v1 output (witness version 1, 2-byte program) that anyone can spend. It serves as a dedicated "anchor" output: either channel partner can attach a CPFP child to the commitment transaction by spending this anchor. Because the output is provably anyone-can-spend, it carries zero economic value—its sole purpose is to enable fee-bumping.
Traditionally, Bitcoin nodes evaluate each transaction independently. A parent transaction below the mempool minimum feerate would be rejected, even if a high-fee child makes the package profitable. This created a chicken-and-egg problem: the parent can't enter the mempool without the child, and the child can't enter without the parent.
Package relay solves this by allowing nodes to evaluate transactions as a group. Bitcoin Core 28.0 implemented limited 1-parent-1-child package relay:
This is particularly important for Lightning: a force-close commitment transaction may have been created hours or days earlier with a fee that is now too low. Package relay ensures the commitment can still be broadcast and confirmed by attaching a high-fee child.
RBF and CPFP ensure transactions can navigate the fee market. Chapter 18 puts these tools to work in the Lightning Network, where reliable fee-bumping is not just a convenience but a security requirement—the ability to get a transaction confirmed within a timelock window can mean the difference between keeping and losing channel funds.
L1. Any \(\texttt{nSequence} < \texttt{0xFFFFFFFE}\) signals RBF replaceability. The cutoff is 0xFFFFFFFE: values \(\geq\) this are final (not replaceable), values \(<\) this signal RBF.
L2. The five BIP 125 rules: (1) The original signals replaceability. (2) No new unconfirmed inputs in the replacement. (3) Higher absolute fee. (4) Replacement pays for its own bandwidth at the minimum relay feerate. (5) No more than 100 transactions evicted.
L3. RBF is a relay policy, not a consensus rule. Individual nodes decide whether to accept replacements into their mempools. Miners can include any valid transaction in a block regardless of RBF rules.
L4. Child-Pays-for-Parent. The recipient benefits—they accelerate a stuck incoming transaction by spending its unconfirmed output in a high-fee child. The sender can also use CPFP via their change output, but the primary use case is recipient-side fee-bumping.
L5. Bitcoin Core 28.0 (October 2024) made full RBF the default by setting the option mempoolfullrbf to 1.
H1. Package feerate \(= (400 + 3,000) / (200 + 150) = 3,400 / 350 \approx 9.7\) sat/vB.
H2. The replacement must pay at least: (a) the original fee: 1,000 sats (Rule 3), plus (b) its own bandwidth: \(300 \times 1 = 300\) sats (Rule 4). Minimum replacement fee = \(1,000 + 300 = 1,300\) sats.
H3. Create a replacement transaction that spends the same input(s) but sends all funds back to your own address (minus the fee). The replacement must pay a higher fee than the original. Since the replacement has no outputs going to the original recipient, the "payment" is effectively cancelled. The original transaction is evicted from the mempool.
H4. Yes, but only if the new child is more incentive-compatible (pays a higher feerate) than the existing child. Under TRUC rules, the existing child is evicted and replaced by the new one. This is one of TRUC's key features: the child slot can always be contested with a better offer. Both children must respect the 1,000-vB TRUC child cap, and the new child's 500 vB satisfies this.
P1. Original: 141 vB at 3 sat/vB = 423 sats fee. Target: 20 sat/vB.
RBF: Replace the 141-vB transaction with \(141 \times 20 = 2,820\) sats fee. Total block space consumed: 141 vB. Total fee paid: 2,820 sats.
CPFP: Keep the original (141 vB, 423 sats). Add a child of 141 vB. The child must bring the package feerate to 20 sat/vB: \((423 + f) / (141 + 141) = 20\), so \(f = 20 \times 282 - 423 = 5,217\) sats. Total block space: 282 vB. Total fee: \(423 + 5,217 = 5,640\) sats.
RBF uses 141 vB less block space and pays 2,820 sats less in total fees. CPFP costs \(5,640 / 2,820 = 2\times\) as much because it pays for two transactions instead of one.
P2. Without Rule 2, an attacker could: (1) Create a low-fee transaction \(A\) spending their own input. (2) Wait for an unrelated unconfirmed transaction \(B\) from another user. (3) Create a "replacement" for \(A\) that also spends an output of \(B\) as a new unconfirmed input. Now \(B\) is entangled with the attacker's replacement—if the replacement is evicted or further replaced, \(B\) may also be affected. This is a form of transaction pinning: the attacker can manipulate another user's transaction's confirmation by tying it to their own replacement chain. Rule 2 prevents this by forbidding new unconfirmed inputs.
P3. Opt-in RBF relied on a gentleman's agreement: non-signaling transactions were treated as "final" by some services (e.g., accepting zero-confirmation payments). But this was never guaranteed by Bitcoin's protocol—miners could always include conflicting transactions. Full RBF acknowledges this reality: no unconfirmed transaction is final. The security assumption that full RBF invalidates is that non-signaling, unconfirmed transactions are safe to treat as irreversible. This assumption was always fragile; full RBF makes the policy match the security model.
C1. We need: bit 31 = 0 (BIP 68 enabled), bit 22 = 0 (block-based), bits 0–15 = 144 (= 0x0090). The result is \(\texttt{nSequence} = \texttt{0x00000090}\). Check: \(\texttt{0x00000090} < \texttt{0xFFFFFFFE}\) (RBF ✓), bit 31 = 0 (BIP 68 ✓, 144-block relative lock), and \(\texttt{0x00000090} < \texttt{0xFFFFFFFF}\) (nLockTime enabled ✓).
C2. The problem: a Lightning commitment transaction created days ago may have a fee too low for current mempool conditions. It cannot be modified (both parties signed it). The old solution (CPFP carve-out with anchor outputs) was limited: the carve-out only allowed one extra child beyond descendant limits, and an attacker could "pin" the anchor by attaching a large, low-fee child that filled the descendant limit. TRUC transactions solve this: the commitment uses \(\texttt{nVersion}=3\), allowing at most one child. If the counterparty attaches a low-fee child, you can evict it by submitting a higher-fee child. Package relay ensures the commitment-plus-child pair can enter the mempool even if the commitment alone is below the minimum feerate. Together, they guarantee reliable fee-bumping under adversarial conditions.
B1. Lightning commitment transactions are pre-signed: the fee is locked in at signing time, which may be hours or days before broadcast. If the fee is too low when broadcast during a force-close, the commitment may not confirm before the CSV timelock expires—allowing the counterparty to claim funds with a revoked state. This is a security-critical failure mode. Anchor outputs (spending outputs attached to each commitment) enabled CPFP fee-bumping. TRUC transactions improved this by preventing pinning attacks. Package relay closed the last gap by allowing below-minimum-feerate parents to enter the mempool when paired with a sufficient child.
B2. A large Ordinals inscription transaction is typically a single transaction with no unconfirmed descendants. To replace it via RBF, the replacement evicts only 1 transaction (\(1 \leq 100\)), so Rule 5 is easily satisfied. The more relevant constraint is Rule 3: the replacement must pay a higher absolute fee. Since large inscriptions may pay significant fees (e.g., a 99,000-vB inscription — just under the 100,000-vB standardness cap — at 10 sat/vB pays 990,000 sats), the replacement must exceed this—potentially expensive. Rule 5 would become relevant only if the inscription had spawned many descendant transactions (up to the limit of 25).