ビットコインにおけるChild-Pays-for-Parent（CPFP）の仕組み - パッケージリレーの仕組み、手数料の計算方法、受信者と送信者のユースケース、RBFとの比較、実際のウォレットでの使用例を解説します。
ビットコインの受取を待っているとします。送信者が手数料を低く設定したため、トランザクションがメムプールで何時間も未確認のままです。RBFは送信者しかトランザクションを置き換えられないため使えません。しかし、手立てがないわけではありません。これから受け取る未確認の出力（output）を使い、マイナーが両方のトランザクションをまとめて確認したくなるほど高い手数料を付けて新しいトランザクションを作成できます。この手法をChild Pays for Parent（CPFP）と呼びます。
CPFPはRBFの補完手段です。RBFが送信者に自分の滞留トランザクションを置き換える手段を与えるのに対し、CPFPは受信者を含む使用可能な出力を持つ誰もが確認を加速できるようにします。この2つが滞留したビットコイントランザクションを解決するための主要なツールです。
CPFPの仕組みは、マイナーがブロックに含めるトランザクションを選択する方法に基づいています。マイナーはトランザクションを個別に評価するのではなく、トランザクションパッケージとして評価します。手数料の低い親トランザクションに手数料の高い子トランザクションが紐づいている場合、合理的なマイナーはパッケージ全体の手数料率が他のトランザクションより高いため、両方を含めます。
手順は以下のとおりです：
子がオンチェーンで有効になるためには、親が必ず先に確認される必要があります。子が使用する出力は親が確認されるまで存在しないからです。この依存関係こそが、マイナーに親を含めることを強制します。
子トランザクションは親の手数料不足分を補填する必要があります。計算式は以下のとおりです：
target_package_fee = desired_rate × (parent_vsize + child_vsize)
required_child_fee = target_package_fee - parent_fee
child_fee_rate = required_child_fee / child_vsize| パラメータ | 値 |
|---|---|
| 親の仮想サイズ | 225 vB |
| 親の手数料 | 450 sats（2 sat/vB） |
| 子の仮想サイズ | 141 vB |
| 目標パッケージ手数料率 | 12 sat/vB |
target_package_fee = 12 × (225 + 141) = 4,392 sats
required_child_fee = 4,392 - 450 = 3,942 sats
child_fee_rate = 3,942 / 141 ≈ 28 sat/vBパッケージ全体を12 sat/vBに引き上げるには、子が約28 sat/vBを支払う必要があります。これは目標手数料率よりかなり高くなりますが、子が親の不足分まで補填するためです。
受信者 - これがRBFに対するCPFPの最大の利点です。誰かが低い手数料でビットコインを送ってきた場合、その未確認の出力を高手数料の子トランザクションで使用できます。送信者の協力は必要ありません。
送信者 - トランザクションに自分のウォレットに戻るお釣り出力がある場合、そのお釣り出力をCPFPの子として使用できます。元のトランザクションでRBFが有効になっていなかった場合に有用です。
使用可能な出力を持つ誰でも - 複数の出力があるトランザクションでは、どの出力の所有者でも子を作成できます。CoinJoinやLightningチャネルクローズなどのマルチパーティプロトコルでも、使用可能な出力を持つ参加者であればCPFPを使えます。
未確認の受信トランザクションを右クリック → "Accelerate Transaction (CPFP)"を選択します。Sparrowが必要な子の手数料を自動的に計算し、トランザクションを作成します。
未確認のUTXOを高い手数料で自分自身に送信します：
bitcoin-cli -named sendtoaddress \
address="your-address" \
amount=0.0009 \
fee_rate=30 \
include_unsafe=trueinclude_unsafe=trueフラグにより、未確認の出力を使用できるようになります。
Historyタブで未確認トランザクションを右クリック → "Child pays for parent."を選択します。Electrumが手数料計算を自動的に処理します。
| CPFP | RBF | |
|---|---|---|
| 使用可能者 | 送信者または受信者 | 送信者のみ |
| メカニズム | 新しい子トランザクション | 置換トランザクション |
| シグナリングの必要性 | 不要 | 必要（opt-in RBF）またはfull RBF |
| 新しいTXIDの生成 | はい（子が独自のTXIDを持つ） | はい（置換トランザクションに新しいTXIDが付与） |
| 親TXIDの変更 | いいえ - 親TXIDは維持 | はい - 元のTXIDは無効化 |
| コスト効率 | 低い（子TXの追加ブロック空間消費） | 高い（単一TX、追加オーバーヘッドなし） |
| 適した場面 | 受信者、non-RBFトランザクション | RBF対応ウォレットの送信者 |
重要な違い：CPFPでは元の親TXIDが有効なまま維持されます。受信者のTXIDは変わりません。一方RBFでは、元のTXIDが無効化され新しいTXIDに置き換えられます。TXIDでトランザクションを追跡する加盟店や決済処理業者にとって、この違いは重要です。
CPFPは、マイナーがトランザクションを個別ではなくパッケージとして評価することに依存しています。これはBitcoin Coreの祖先手数料率（ancestor fee rate）計算を通じて実装されています。
ブロックテンプレート用のトランザクション選択時、Bitcoin Coreは各トランザクションの祖先手数料率を計算します - そのトランザクションとすべての未確認祖先の合計手数料を、結合した仮想サイズで割った値です。トランザクションは祖先手数料率でソートされ、収益性の高いパッケージがまとめて含まれます。
子トランザクションがメムプールに受け入れられるには、親がすでにメムプールに存在するか、パッケージリレーを通じて同時に送信される必要があります。Bitcoin Coreは祖先チェーンと子孫チェーンに以下の制限を適用します：
これらの制限は、過度に長いトランザクションチェーンによるサービス拒否攻撃を防ぎつつ、実用的なCPFPの使用を可能にしています。
従来、CPFPにはニワトリと卵の問題がありました：親の手数料率がメムプールの最低値を下回ると、子が送信される前にノードが親を拒否していました。パッケージリレー（Bitcoin Coreで段階的に実装）は、親と子を単一のパッケージとして送信し、まとめて評価することでこの問題を解決します。
これはLightning Networkの強制クローズトランザクションにとって特に重要です。手数料急騰時に事前署名された手数料が不十分になる可能性があるためです。
CPFPはLightning Networkのセキュリティにおいて重要な役割を果たします。チャネルが強制クローズされると、コミットメントトランザクションはチャネルが最後に更新された時点の手数料でブロードキャストされます - それが数日から数週間前の可能性もあります。その間に手数料が上昇していた場合、コミットメントトランザクションが滞留する可能性があります。
Lightningの実装はアンカー出力（anchor outputs）を使用します - CPFPで使用するために設計された小さな出力です。チャネルの各当事者は、コミットメントトランザクションの実効手数料率を引き上げるために使用できるアンカー出力を受け取ります。これにより、手数料が急騰しても、チャネルクローズが適時に確認されることが保証されます。