Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 10 of 21

Fee changes: RBF and CPFP

Understand two mechanisms before relying on a rescue button.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 10 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Compare replacement and child-pays-for-parent concepts.
  • Recognize wallet and policy constraints.

A replacement changes the proposed spend

Replace-by-fee concerns replacing an unconfirmed transaction with a competing transaction that pays a more attractive fee under applicable node policy. BIP 125 documents an opt-in approach; actual software policy can evolve. A replacement can change the transaction identifier and may change outputs, so an application must reconcile the final transaction rather than trusting an old identifier forever.

A child can make a package more attractive

Child-pays-for-parent uses a transaction spending an output of an unconfirmed parent. A sufficiently attractive combined fee can encourage inclusion of the package under supported policies. This requires a spendable output and appropriate wallet behavior. It is not a universal ability to modify somebody else’s transaction or to force a miner to include it.

Plan observability before urgency

An artist checkout should keep order identity separate from transaction identity because replacement and multiple payment attempts complicate the mapping. A fee bump is not a new sale. Before a real action, inspect the current wallet documentation, transaction state, amounts and total fee. This course provides a paper comparison only; it does not instruct you to use a paid acceleration service or modify a live transaction.

Practice on paper

A pending payment changes from identifier A to identifier B after an authorized fee replacement. What should an invoice system preserve?

Reveal the worked answer

It should preserve the order and intended payment relationship while tracking the replacement and final settlement. It must avoid counting A and B as two independent settled donations.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does fee replacement guarantee a specific confirmation time?

  • Yes
  • No
Reveal answer 1

No. Mining and policy remain relevant.

2. Does CPFP let anyone spend an output they cannot authorize?

  • Yes
  • No
Reveal answer 2

No. The child still needs valid spending authorization.

Take this with you

A fee-management action needs its own reconciliation trail.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.