CPFP (Child Pays for Parent)

Anna は 100 000 sat の受け取りを待っています。sat はビットコインの最小単位である satoshi の略です。支払いは見えていますが、送信者の設定した手数料が低く、まだブロックに入っていません。Anna のウォレットは、この未確認の出力を使えるようになっています。そこで、自分のアドレスへ送る新しい取引を作り、より高い手数料を付けます。送信者や特別なサービスに報酬を払うのではなく、通常のビットコインの取引手数料を払うのです。マイナーは元の取引なしに新しい取引を確認できません。元の取引がなければ、検証するチェーンに必要な出力が存在しないためです。親は先に確認済みであるか、同じブロックの中で子より前に置かれる必要があります。ほかに必要な未確認の祖先取引があれば、それらも先に取り込む必要があります。逆の制約はなく、親は子なしでも確認されます。 [3] [5]

ほかに未確認の祖先取引がない単純な例を考えましょう。親のサイズは 200 vB、手数料は 200 sat です。vB は仮想バイトで、取引のウェイトから求めるサイズの単位です。sat/vB は、その単位あたりに何 satoshi を払うかを表します。子のサイズは 100 vB で、Anna は 2 800 sat の手数料を払います。子の出力が一つだけなら、受け取った 100 000 sat のうち 97 200 sat が残ります。両方を合わせると、300 vB に対して 3 000 sat、つまり 10 sat/vB です。子だけなら 28 sat/vB ですが、マイナーは手数料の低い親も取り込まなければなりません。子の高い数字だけを見ると、この依存関係を見落とします。これは計算例であり、今日の推奨レートではありません。実際のサイズと必要な合計手数料はウォレットが確認します。ほかに必要な祖先取引があれば計算も変わります。詳しい補足として、取引を検証して中継するプログラムであるノードが、パッケージをローカルに受け入れる際は、すでに受け入れた取引を再び数えず、補正された手数料を使うこともあります。その場で表示されるレートは、ここでのマイナー向けの単純な合算と一致するとは限りません。 補正された手数料は、ノードが判断に使うローカルな値です。取引が実際に支払う手数料は変わりません。 [3]

CPFP は、誰でも他人の取引を速められるボタンではありません。親の出力を使う権限があり、署名を含む使用条件を満たす必要があります。Anna は受取人としてそれができます。送信者は、自分の残額が戻る change、つまりお釣りの出力を使える場合があります。エクスプローラーや Watch-only Wallet で金額が見えるだけでは足りません。 Watch-only Wallet は支払いを確認するためのウォレットで、資金を使うための秘密鍵をそれ自体には保持しません。ウォレットも未確認の出力の使用に対応している必要があります。署名前には、どの出力を使うか、どこへ送るか、いくら残るか、合計手数料はいくらかを確認しましょう。出力が小さいと、手数料がその大部分を占めることもあります。 [5]

Replace-by-Fee (RBF) は、元の取引を置き換えるための、新しい競合する取引を作ります。少なくとも一つの同じ入力を使いますが、入力の組み合わせ全体が同一である必要はありません。CPFP は元の支払いとその識別子を残し、別の取引を追加します。RBF には置換先の入力の条件を満たすことが必要です。通常の CPFP では、元の支払いの出力の条件を満たします。そのため、受取人は送信者の置換取引に署名できなくても CPFP を使える場合があります。無関係な別の支払いに高い手数料を付けても助けにはなりません。子は、確認待ちの支払いに実際に依存している必要があります。 [3]

合計の手数料レートが上がると、マイナーには両方を選ぶ理由が増えます。ただし、次のブロックの場所を予約するわけではありません。もっと高い手数料の取引が届くかもしれず、パッケージが一部のマイナーに届かない可能性もあります。元の支払いと子の両方の確認状況を追いましょう。ノードが受け入れたという表示は、まだブロックでの確認ではありません。送信者が RBF で元の支払いを置き換えた場合、古い出力を参照する子が別の新しい取引へ自動的につながることはありません。状況を改めて確かめる必要があります。子を作っても、未確認の入金が確実な支払いに変わるわけではありません。 [3]

ここからは、さらに詳しく知りたい人や自分のノードを使う人向けのルールです。Mempool は特定のノードが持つ確認待ち取引の一覧で、ネットワーク全体の共通の列ではありません。パッケージは一緒に提出する取引の集まりです。取引が有効か、ノードが受け入れるか、マイナーが選ぶかという三つの判断を分けて考えることが大切です。 コンセンサスはトランザクションとブロックの有効性を決めます。mempool ポリシーはローカルでの受け入れと中継、マイナーの規則は候補ブロックへの選択を決めます。CPFP はコンセンサスを変更しません。経済的に有利なパッケージでもローカル規則に反する場合があり、一つのノードによる受け入れは他のノードやマイナーを拘束しません。 [3] [5]

親と子をまとめて転送する仕組みは進化しています。Package CPFP は、関連する取引をパッケージとして評価することを指します。RPC はノードを操作するコマンドです。minrelaytxfee は通常の転送に必要な最低レートを表します。TRUC は祖先と子孫の関係を制限する特別な取引ルールです。以下の経緯は、記載された Bitcoin Core のバージョンについて説明しています。 Bitcoin Core 26 は submitpackage RPC と package CPFP を追加しました。子は mempool の動的最低手数料率を下回る親を支援できましたが、当時は最低中継手数料率を下回る親は対象外でした。この制限は不変ではありません。Core 31 は対応する親一つ・子一つのパッケージ中継で、minrelaytxfee を下回る親や手数料ゼロの親も、TRUC 以外を含めて許可します。子に他の未確認親がある場合、それらは既に mempool に存在する必要があります。ローカルで受け入れられても、ネットワーク全体で同じように伝播する保証はありません。 [1] [2]

ノードは無制限に大きな依存関係の網を受け入れられません。祖先は別の取引より先に必要になる取引で、子孫はその先の出力を使う取引です。WU は取引のウェイトの単位、トポロジーは取引のつながり方を指します。こうした技術的な上限は、該当バージョンのノードのポリシーです。 制限はメモリ、プロセッサの処理能力、帯域を保護します。古い Core は祖先と子孫の数やサイズを制限しましたが、Core 31 はこれらの mempool 制限を接続された cluster の制限に置き換えました。独立したパッケージ制限は残り、Core 31 文書では最大 25 トランザクション、合計ウェイト 404000 WU です。ウェイトは仮想サイズではありません。不適切な構造、競合、ノードが受け入れる取引形式に関するローカルな条件（標準性）への違反は十分な手数料があっても CPFP を妨げます。 [2] [3]

依存関係のある確認待ち取引は、経済的な価値をいつも個別に評価できるとは限りません。Cluster Mempool では、ノードがつながったグループとして扱えます。cluster はつながったグループ全体、chunk は取引を選ぶ際に処理する、より小さなグループです。確認済みブロックの断片ではありません。 Bitcoin Core 31 は Cluster Mempool を使います。cluster は親子関係を方向を問わずたどってつながるトランザクションの集合です。既定値は cluster 当たり 64 トランザクションと仮想サイズ 101 kB で、設定可能です。順序は一緒に採掘される chunks というグループとその手数料率を考慮します。過去の CPFP carveout は子孫制限への限定的な例外でしたが、Core 31 で廃止されました。この方法で cluster のトランザクション数制限を回避することはできません。 [2] [4]

この節のコマンドは同じものではありません。テストは結果を示すだけの場合がありますが、パッケージの提出は署名済み取引を実際に受け入れて転送することがあります。vsize は仮想サイズを示す項目です。通常のウォレットは、これらの細部を利用者に代わって処理できます。 Core 31 の getmempoolentry RPC は、そのノードの mempool にある取引の手数料、vsize、依存関係、chunk のデータを示し、getmempoolcluster は関連 cluster を示します。testmempoolaccept RPC は受け入れや配信をせずローカルで試験します。複数取引では祖先を子孫より先に並べ、相互にも mempool とも競合させてはいけません。submitpackage RPC は対応するパッケージを実際に mempool への受け入れと中継に提出するもので、単なる試験ではありません。各取引の結果、バージョン、設定を確認してください。どの結果もブロックへの取り込みを保証するものではありません。 [2] [6] [7] [8] [9]