MASTERING-BITCOIN · Interactive Practice | Unit 10 · Video 2
| Concept | Formula / Rule | Meaning |
|---|---|---|
| Fee rate | Sats per virtual byte — what miners actually prioritize | |
| Implicit fee | What's left over goes to the miner | |
| RBF rule 1 | Replacement must out-bid on rate | |
| RBF rule 2 | Replacement must pay more total fee | |
| Chain safety | Every replacement spends every input prior versions spent | Guarantees mutual conflict |
The original transaction spends 1 BTC as input, pays the recipient 0.5 BTC, sends some change back, and leaves the remainder as the miner fee.
Use the slider below to shrink the change output. Whatever you take away from the change flows directly into the fee. Watch how the fee rate and the RBF relay-rule checklist update.
⚙ interactive visualization — coming to this page format soon
The video warns about a hazard: if you keep replacing a transaction but drop inputs along the way, the chain can break. Two non-overlapping versions can both confirm, and the recipient gets paid twice.
Toggle the dropdowns to choose which inputs each version spends. The diagram will show which versions actually conflict — and which pair is dangerous.
⚙ interactive visualization — coming to this page format soon
Reflect: Try setting v1 to spend A, B and v2 to spend B, C. Notice that v0 (just A)
and v2 (B, C) share no input — they don't conflict, so a miner could mine both in different blocks.
The discipline from the video: every replacement must contain every input from every prior version.
Setting v2 to A, B, C restores the chain.
Question 1
An original transaction spends one input of 1 BTC, pays the recipient 0.5 BTC, has a change output of 0.4999 BTC, and a fee of 0.0001 BTC.
You build an RBF replacement that keeps the same input and same payment but shrinks the change output to 0.4995 BTC. What is the new fee?
✅ Correct! Every satoshi removed from change becomes fee.
❌ Not quite. That's the increase in fee — but the question asks for the total new fee. Add the original 0.0001.
❌ Not quite. Use: fee = inputs − outputs. The input is still 1 BTC; the outputs are now 0.5 + 0.4995.
Solution:
The fee is the implicit difference between inputs and outputs:
That's 5 times the original fee. The 0.0004 BTC you removed from the change output flows directly into the fee because the input total is fixed at 1 BTC.
Question 2
True or False: A merchant who is waiting for an incoming payment to confirm can use RBF to bump the fee on that stuck transaction and get it mined faster.
✅ Correct! RBF needs the sender's signing keys. Receivers use CPFP instead.
❌ Not quite. RBF requires re-signing the inputs, and only the holder of the input UTXOs has those keys.
Solution:
RBF requires building a new transaction that spends the same inputs as the original. Inputs are UTXOs that belong to the sender — only the sender holds the private keys needed to produce valid signatures for them. A receiver has no signing authority over the sender's UTXOs.
The receiver's tool for bumping a stuck incoming payment is Child Pays For Parent (CPFP): the receiver spends the unconfirmed output in a new high-fee child transaction. Miners must mine the parent to mine the child, so the child's fee effectively raises the parent's priority.
Question 3
Your original transaction is 200 virtual bytes with a fee of 2,000 sats (10 sat/vB). You build a replacement that is also 200 vB and pays 2,400 sats in fees (12 sat/vB).
Which is true about how relay nodes evaluate this replacement?
✅ Correct! The fee numbers are fine; whether the replacement is accepted depends on the node's policy (BIP125 vs. full RBF).
❌ Almost. The relay-rule numbers pass, but you've ignored the signaling layer — under classic BIP125, the original must have signaled replaceability for nodes to accept this.
❌ Not quite. There is no minimum-percentage or doubling rule. The two hard rules are: higher fee rate and higher absolute fee. Signaling is the separate question.
Solution:
Two things are being tested here:
Relay rules: A replacement must pay a higher fee rate (12 > 10 sat/vB) and a higher absolute fee (2,400 > 2,000 sats). Both pass — there is no "minimum increment percentage" or "must double" rule in the core RBF policy.
Signaling: Under classic BIP125 opt-in RBF, nodes only accept a replacement if the original
signaled replaceability (an input's sequence value below 0xFFFFFFFE). Under full RBF, nodes
ignore the signal and accept any conflicting replacement that passes the relay rules.
So the most precise answer is: the replacement passes the rate/fee tests, but acceptance depends on whether the node enforces BIP125 opt-in or full RBF.
Question 4
A sender publishes the following chain of replacements:
What is the danger in this chain?
✅ Correct! Replacement only happens through conflict, and v0 and v2 don't conflict — that's the bug.
❌ Not quite. Conflict requires a shared outpoint. Check whether every pair in the chain shares at least one input — including v0 and v2.
Solution:
Two transactions conflict only when they try to spend a common outpoint. Check the pairwise sets:
A miner could mine v0 in one block and v2 in another. Both are valid simultaneously. The recipient receives the payment twice, both times paid out of the sender's wallet.
The fix: every replacement must spend every input that any prior version spent. If v2 spends A, B, and C, then v2 also conflicts with v0 on input A, and mutual exclusion is restored.
Solved: 0 / 4