Package Relay は関連する未承認トランザクションをノード間で転送し、メモリプールへの受け入れ時に親と子をまとめて評価できるようにします。データ転送、各ノードの受け入れ方針、マイナーによるブロックへの選択は別の段階です。パッケージは個々のトランザクションのコンセンサス上の有効性を変えません。
手数料率の低い親は、ノードが高い手数料を払う子を見る前に拒否されることがあります。必要なトランザクションがマイナーに届いて初めて、CPFP は経済的な誘因になります。Package Relay はこの転送上の隙間を埋める助けになりますが、署名や入力の検証を代替しません。 [BIP 331 — Ancestor Package Relay]
例として、親は 200 vB で手数料 200 sat、子は 100 vB で手数料 1300 sat とします。合計では 1500 / 300 = 5 sat/vB となり、個別の率 1 と 13 の平均ではありません。この例は他の祖先を持たない二つの未承認トランザクションだけを想定しています。実際の受け入れにはノードの方針や競合も影響します。 [BIP 331 — Ancestor Package Relay]
子は親の出力を使用します。トポロジカル順に並べたリストでは親が子より先に必要であり、高い手数料でも祖先の欠落や競合する支出は修復できません。パッケージのサイズ、数、形に対する制限はノードの資源を保護するもので、普遍的なコンセンサスのパラメーターではありません。 [Bitcoin Core 28.0 — submitpackage]
BIP 331 は対応状況の交渉と、祖先情報およびトランザクション取得のための専用メッセージを記述します。一方、Bitcoin Core 28.0 が記録したのは、既存の中継プロトコルで一つの親と一つの子を機会的に組み合わせる限定的な対応です。ローカル RPC が複数の親を許しても、P2P が同じ対応を持つとは限りません。これはバージョン 28.0 の説明で、すべてのバージョンやピアへの約束ではありません。 [BIP 331 — Ancestor Package Relay] [Bitcoin Core 28.0 — release notes]
submitpackage 28.0 はトランザクションを検証し、ローカルノードに提出します。package_msg と個別の tx-results の両方を確認してください。一部だけを受け入れる場合があるため、失敗時にすべてを一括で取り消す操作ではありません。全件成功しても、隣接ノードの受け入れやマイナーによる期限内の取り込みは証明されません。 [Bitcoin Core 28.0 — submitpackage]
分離したテスト環境で、バージョン、メモリプール設定、依存順、サイズ、手数料を記録します。testmempoolaccept は配信せず検査しますが、その結果は submitpackage の保証ではありません。別のノードでの受け入れも観察します。時間制約のある Lightning トランザクションには依然として余裕が必要です。パッケージ対応だけでは pinning、混雑、ブロック生成の遅れを解消できません。 [Bitcoin Core 28.0 — testmempoolaccept] [Bitcoin Core 28.0 — release notes]
理解を深めるには、この項目とあわせて次もお読みください Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network. 次の項目からも参照されています CPFP (Child Pays for Parent), Gloria Zhao.