Package Relay は、関連する未承認のトランザクションをBitcoinのノードがまとめて転送・評価する仕組みです。先のトランザクションの手数料が少なくても、その出力を使う後続のトランザクションが両方に十分な手数料を追加できる場合に役立ちます。妥当性やノード独自のルールは引き続き適用され、まとめて評価されても承認が保証されるわけではありません。
アンナはビットコインの支払いを待っています。送金者が低い手数料を設定した後、ブロックの空き容量への需要が増えました。ブロックは、共有する履歴に追加する取引のまとまりです。ノードは、取引やブロックを検証し、ネットワークの他の参加者と通信するソフトウェアです。そのため、一部のノードはこのトランザクションを自分の mempool、つまり未承認トランザクションの一時的な保管場所に受け入れません。アンナは後続のトランザクションで手数料を足したいのですが、それは拒否したノードがまだ入金を把握していないコインを使います。Package Relay は必要な関連情報を届け、手数料の少ない最初のトランザクションだけを孤立して評価する状況を改善します。 [1] [6]
先のトランザクションを親、その出力を使うものを子と呼びます。出力とは、決められた条件を満たせば使える具体的な金額です。アンナが親の出力の使用条件を満たせるなら、子を作れます。例えば、受け取るコインを自分の別のアドレスへ移し、一部を手数料に回す方法です。これが CPFP (Child Pays for Parent) で、子の高い手数料が両方の承認を後押しします。Package Relay は転送と評価を助けますが、手数料の支払いも署名も代行せず、他人のコインを使う権限も与えません。 [1] [5]
親のサイズが 200 vB、手数料が 200 sat、子のサイズが 100 vB、手数料が 1300 sat とします。vByte（vB）は、通常の手数料計算に使う仮想的なトランザクションサイズの単位で、sat はbitcoinの小さな単位です。合計は 300 vB に対して 1500 sat、つまり 5 sat/vB です。個別の料率である 1 と 13 sat/vB の単純平均ではありません。ここでは未受理のこの二つだけを考え、他の未承認の祖先やローカルな手数料調整はないとします。実際のノードは受理済みのトランザクションを二重に数えないため、どの依存関係を評価しているかが重要です。 [5] [3]
子の入力は親の出力を参照します。まとめて評価する意味はあっても、欠けているコインの履歴を無視することはできません。リストでは、含まれる各親を子より前に置きます。これをトポロジカル順序と呼びます。署名やその他の妥当性ルールも引き続き検証されます。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。同じコインを使う二つのトランザクションは、手数料を足しても両立しません。パッケージの件数、サイズ、構造の制限はノードの負荷も抑えるもので、いくらでも長い連鎖を送れるわけではありません。 [5] [3] [7]
ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。到達とはノードがデータを得たこと、受理とはそのルールに従って mempool に入れたことです。承認にはブロックへの収録が必要です。mempool はノードごとに異なり、一つで成功しても隣の判断は分かりません。Bitcoin Core 28.0 では、合算料率が混雑した mempool の変動する最低料率を満たす助けになりますが、別にある最低中継料率を一般的に取り払うものではありません。同版には、特別な制限を持つ TRUC Transactions に例外があります。高い手数料の子が、どんな親でも救えるわけではないのです。 [2] [5] [8]
Gloria Zhaoの BIP 331 は、対応機能の交渉や、祖先情報とトランザクション本体を要求するメッセージを記述した、より広い提案です。一方、Bitcoin Core 28.0 が記録したのは、既存のネットワークプロトコルで一つの親と一つの子を組み合わせる限定的な機能でした。ローカルのプログラミングインターフェースである RPC は、複数の独立した親を持つ子も受理できましたが、ノード間の中継まで同じ能力があるという意味ではありません。これはそのバージョンの説明であり、別の版では文書と相手ノードの対応状況を確認する必要があります。 [1] [2]
Bitcoin Core 28.0 の submitpackage は、準備したパッケージをローカルノードに提出するコマンドです。子とその未承認の親を指定し、親同士は依存せず、子を最後に置きます。package_msg だけでなく個別の tx-results も読みます。ノードはパッケージの一部だけを受理することがあり、エラーが出ても受理済みのすべてが自動で取り消されるわけではありません。全体が成功しても、ネットワーク全体への伝播や承認の証明にはなりません。汎用の送金加速サービスではなく、アドレスだけでなく正しく構築したトランザクションが必要です。 [3]
隔離したテスト環境では、testmempoolaccept でブロードキャストせずに受理を調べられます。別のトランザクションが失敗すると、十分に検証されなかったものには allowed がない場合があります。テスト呼び出しと submitpackage の条件も完全には一致しません。バージョン、設定、依存関係、サイズ、手数料を記録し、別ノードでの受理も別途観察します。Lightning Network の期限に敏感なトランザクションでは、依然として適時の対応が必要です。Package Relay だけでは混雑、不規則なブロック間隔、pinning、つまり mempool のルールを意図的に利用して手数料引き上げを妨げる行為はなくせません。 [4] [2] [1]
理解を深めるには、この項目とあわせて次もお読みください Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. 次の項目からも参照されています CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.