bitcoin-dev-project · jrakibi · Mar 16, 2025 · Mar 15, 2025
diff --git a/decoding/cpfp.mdx b/decoding/cpfp.mdx
@@ -0,0 +1,93 @@
+---
+title: "Child Pay For Parent (CPFP)"
+date: 2024-01-25T15:32:14Z
+lastmod: "2024-07-26"
+draft: false
+category: Transactions
+layout: TopicBanner
+order: 4
+icon: "FaClipboardList"
+images: ["/decoding-bitcoin/static/images/topics/thumbnails/musig-thumbnail.webp"]
+parent: "fee-calculation"
+---
+
+Imagine receiving bitcoin but the transaction is stuck in the mempool.  
+The sender used a fee that's too low, and miners aren't picking it up.  
+
+<div className="dark:hidden w-full rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/transactions/fees/cpfp-1.svg"
+        width="100%"
+        height="auto"
+    />
+</div>
+<div className="hidden dark:block w-full rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/transactions/fees/cpfp-1.svg"
+        width="100%"
+        height="auto"
+    />
+</div>
+
+What can you do? This is where Child Pays For Parent (CPFP) comes in.
+
+
+## What is CPFP?
+
+CPFP is a fee-bumping strategy where the recipient of an unconfirmed transaction creates a new transaction (child) that spends the pending funds and includes a high enough fee to incentivize miners to confirm both transactions together.
+
+
+## How Does CPFP Work?
+
+Let's break it down with an example:
+
+1. Alice sends 1 BTC to Bob with a very low fee
+2. The transaction gets stuck in the mempool because miners ignore low-fee transactions
+3. Bob creates a new transaction (child) spending the unconfirmed bitcoin
+4. Bob attaches a high fee to the child transaction
+5. Miners see they can collect both fees by including both transactions
+6. Both transactions get confirmed in the next block
+
+
+<div className="dark:hidden w-full rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/transactions/fees/cpfp-2.svg"
+        width="100%"
+        height="auto"
+    />
+</div>
+<div className="hidden dark:block w-full  rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/transactions/fees/cpfp-2.svg"
+        width="100%"
+        height="auto"
+    />
+</div>
+
+## Technical Details
+
+CPFP works because of two key Bitcoin concepts:
+
+1. **UTXO Model**: Bitcoin allows spending unconfirmed outputs, enabling the creation of child transactions
+2. **Mempool Package Evaluation**: Miners evaluate related transactions as a package, considering their combined size and fees
+
+### Fee Calculation
+
+The effective fee rate for a CPFP package is:
+
+<div className="text-center my-4 text-orange-500">
+  $$\text{Effective Fee Rate} = \frac{\text{Parent Fee + Child Fee}}{\text{Parent Size + Child Size}}$$
+</div>
+
+CPFP is particularly useful when:
+- You receive a transaction with too low fees
+- The sender didn't enable RBF (Replace-By-Fee)
+- You need urgent confirmation of incoming funds
+
+## Limitations
+
+While powerful, CPFP has some constraints:
+- Only the recipient can initiate CPFP
+- Requires enough funds to cover the new transaction fee
+- Some wallets don't support CPFP natively
+- May not work during extreme network congestion
diff --git a/decoding/fee-calculation.mdx b/decoding/fee-calculation.mdx
@@ -8,7 +8,7 @@ layout: TopicBanner
 order: 306
 icon: "FaClipboardList"
 images: ["/decoding-bitcoin/static/images/topics/thumbnails/transaction-module/fees-thumbnail-feecalculation.jpg"]
-children: ["transaction-weight", "blocksize-blockweight", "fee-rate", "rbf"]
+children: ["transaction-weight", "blocksize-blockweight", "fee-rate", "rbf", "cpfp"]
 ---
 
 ## Topics:

diff --git a/decoding/network-propagation.mdx b/decoding/network-propagation.mdx
diff --git a/decoding/rbf.mdx b/decoding/rbf.mdx
@@ -1,5 +1,5 @@
 ---
-title: "RBF"
+title: "Replace-By-Fee (RBF)"
 date: 2024-01-25T15:32:14Z
 lastmod: "2024-07-26"
 draft: false
@@ -11,4 +11,42 @@ images: ["/decoding-bitcoin/static/images/topics/thumbnails/musig-thumbnail.webp
 parent: "fee-calculation"
 ---
 
-(coming soon)
+
+Imagine you send a Bitcoin transaction to your friend. You eagerly wait for it to be confirmed, but it gets stuck in the mempool.  
+
+Why? **Because the fee you set was too low**, and miners aren't interested in including it in a block.
+
+## The Problem
+
+Your transaction is sitting in the mempool, unconfirmed for 48 hours. Frustrated, you wonder why it's taking so long. The answer is simple: your transaction fee is too low, and no miner is picking it up.
+
+<div className="dark:hidden w-full rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/topics/transactions/fees/rbf-1.jpg"
+        width="100%"
+        height="auto"
+    />
+</div>
+<div className="hidden dark:block w-full rounded-lg">
+    <SvgDisplay
+        src="/decoding-bitcoin/static/images/topics/transactions/fees/rbf-1.jpg"
+        width="100%"
+        height="auto"
+    />
+</div>
+
+## The Solution: RBF
+
+To fix this, you can use Replace-By-Fee (RBF). RBF allows you to replace your stuck transaction with a new one that offers a higher fee, making it more attractive to miners.
+
+## How Does RBF Work?
+
+To increase the fee, you create a conflicting version of the transaction. This new transaction spends at least one of the same UTXOs as the original transaction you want to replace.  
+
+By doing this, you signal to the network that your transaction can be replaced by one with a higher fee.
+
+## Types of RBF
+
+1. **Opt-in RBF**: Here, the transaction must specify and signal to miners that it can be replaced by a higher fee transaction. This is done by setting the `nSequence` to a value below `0xffffffff`.
+
+2. **Full RBF**: Any unconfirmed transaction can be replaced without signaling. This method offers more flexibility but may face network policy restrictions.