Replace-by-Fee (RBF)

Anna は 20,000 sat を送りましたが、支払いはまだ確認待ちです。 sat は bitcoin の最小単位 satoshi の略です。 ウォレットには RBF で手数料を上げる機能があります。単純な例では、元の取引は 50,000 sat を使い、受取人に 20,000 sat、手数料に 200 sat、Anna へのお釣りに 29,800 sat を割り当てます。置換取引では受取額を 20,000 sat のままにして、手数料を 2,000 sat、お釣りを 28,000 sat にできます。これは仕組みを説明する数字で、現在の推奨手数料ではありません。署名前に Anna はアドレス、受取人の金額、新しい手数料総額を確認します。ウォレットは必要な入力に署名できなければならず、ハードウェアウォレットを再接続する場合もあります。置換取引には新しい txid、つまり取引識別子が付くため、受取人へ新しい確認用リンクを知らせる必要があるかもしれません。手数料の増額と、別の UTXO で独立した二件目の支払いを作ることは違います。独立した二件は両方とも確認され、二重に支払う可能性があります。 [1] [2] [12]

ウォレットは最初の確認より前に入金を表示することがあります。これは zero-conf と呼ばれ、支払いは観測されていますが、まだブロックに入っていません。別のバージョンが先に確認され、表示された入金が消える可能性もあります。そのため ‘RBF 無効’ という表示だけでは支払いが確実だとは言えません。未確認の支払いで商品を渡すのは、事業上のリスクを引き受ける判断です。ブロックに含まれた取引を RBF で書き換えることはできません。チェーン再編の可能性は別のリスクであり、重要な支払いで複数の確認を待つ理由になります。 [1]

RBF 自体は元の受取人を維持するよう求めていません。置換取引は手数料だけを上げて同じ相手に支払うことも、別の場所へ資金を送ることもできます。両方の取引が同じ UTXO を使おうとするので、技術的には競合する使用の試み、Double Spend です。ただし、この言葉だけで詐欺と判断できるわけではありません。攻撃者が他人の支払いに自由に署名できるわけでもありません。置換取引も必要な署名を含む使用条件を満たす必要があります。ウォレットが自分宛ての取引への置換を ‘キャンセル’ と表示していても、元の取引より先に確認されることを狙う操作であり、確実な取り消しではありません。 [1]

RBF は確認待ちの取引そのものを変更します。Child Pays for Parent (CPFP) は元の取引を残し、その出力の一つを使う新しい取引を作ります。マイナーが新しい取引の手数料を得るには元の取引も含める必要があるため、両者を合わせた手数料率で判断できます。新しい取引を子、元の取引を親と呼びます。対象の出力を使える人、たとえば受取人や、お釣りを使う送信者が子取引を作れます。実行できるかどうかはウォレットの対応、必要な署名、取引の依存関係によります。CPFP は元の支払いを置き換えず、確認時刻も保証しません。 [2]

Mempool は Bitcoin 全体で共有する一つの待ち行列ではありません。各ノードが自分の一覧と、確認待ち取引を受け入れ中継するための規則を持っています。RBF はこのローカルな方針に属し、ブロックの有効性を決める合意規則ではありません。そのためマイナーは、別のノードが保存していなかった有効な競合取引を選べます。Full Node はその後、ブロック全体を Bitcoin の規則で検証します。以前の mempool の選好が検証結果を決めることはありません。一つのノードで置換が受け入れられても、すべてのノードで受け入れられる保証はありません。 [1] [6]

利用者に重要なのは、総額でいくら払うかと、取引サイズに対してどの手数料率を提示するかという別々の数字です。仮にサイズが 200 vB なら、200 sat は 1 sat/vB、同じサイズの 2,000 sat は 10 sat/vB です。仮想バイト vB は取引の重みから求めるサイズ単位です。取引を組み直すとサイズも変わり得るので、ウォレットは手数料率も計算し直す必要があります。 手数料総額は satoshi 単位の金額、手数料率は仮想バイト当たりの sat/vB です。Core 30 の単一置換では、排除される全取引の手数料合計に加え、置換取引のサイズと incrementalrelayfee に応じた費用を払います。手数料率は直接競合する各取引の率を上回る必要があります。率だけを上げたり satoshi を足したりするだけでは不十分です。Core 30 の incrementalrelayfee の既定値は 0.1 sat/vB ですが、ノード設定は異なり得ます。 [2] [9]

最初の、まだ確認されていない取引の出力を、すでに別の確認待ち取引が使っている場合があります。こうした後続の取引を子孫と呼びます。親が除去されると、子孫も mempool 内で使用できなくなるため、ノードは影響を受けるグループ全体を検討します。 親取引の置換は、その出力を使う子孫も mempool から排除し得るため、必ずしも二つの取引だけの比較ではありません。Core 30 の単一置換では、直接競合する取引自身を含む子孫数の合計を 100 以下に制限します。共通の子孫を複数回数える場合があります。パッケージの手数料や依存関係が置換の成功に影響します。 [2]

ノードは、置換の計算を何度も繰り返させることで過負荷にされないようにする必要もあります。これはサービスの利用可能性を狙う DoS 攻撃への対策です。UTXO は以前の取引の未使用出力で、新しい取引の入力がそれを参照します。以下は Bitcoin Core 30 の具体的な規則であり、Bitcoin の不変の法則ではありません。 Bitcoin Core 30 の単一置換取引の方針は、新しい未確認入力や排除する取引数も制限します。同じ UTXO を使用するだけでは足りず、ノードが受け入れる取引形式に関するローカルな条件（標準性）と、中継および有効性の規則を満たす必要があります。制限は計算資源、メモリ、帯域を保護します。パッケージ置換の規則はノードのバージョンごとに別途評価する必要があります。 Core 31 では Cluster Mempool の導入により、このポリシーが変わりました。関連する未確認取引をグループとして評価します。置き換えは、累積手数料と順に使用する領域を比較する「feerate diagram」を改善する必要があります。十分な合計手数料や、置き換え取引の中継に必要な追加手数料など、ほかの条件も引き続き適用されます。上記の Core 30 の制限を新しいバージョンにもそのまま当てはめず、自分のノードのルールを確認してください。 [2] [13]

なぜ一部のウォレットには今も RBF の切り替えがあるのでしょうか。当初の opt-in RBF 方針を採用したノードは、置換を許可する事前のシグナルを要求していました。Bitcoin Core 24 ではその条件を不要にする full-RBF を設定できるようになり、Core 28 で既定で有効となり、Core 29 で mempoolfullrbf の設定が削除されました。以下の BIP125 の詳細は元のシグナル方式であり、現在のすべてのノードに共通する規則ではありません。 BIP125 は少なくとも一つの入力の nSequence が 0xfffffffe 未満なら明示的 opt-in とする方式と、未確認の祖先からのシグナル継承を記述しています。これは歴史的な方針であり合意条件ではありません。Full-RBF はこのシグナルなしでも置換を評価するため、シグナルがなくても置換不能とは限りません。 [1] [3] [4] [5] [6]

ここからは自分のノードを操作する人向けです。RPC はソフトウェアへの問い合わせや操作に使うコマンドで、手数料増額ボタンを使うだけなら覚える必要はありません。 getmempoolentry はそのノードの mempool にある取引の状態を示し、testmempoolaccept は署名済みの置換候補一件を、そのノードの現在の mempool と規則に照らして送信せずに試験します。他のノードの受け入れや採掘を保証する結果ではありません。Core 28 は mempoolfullrbf の既定値で full-RBF を有効にし、Core 29 はその設定を削除しました。getmempoolinfo は手数料設定を示しますが、Core 30 の fullrbf フィールドは非推奨です。必ずバージョンと実際の設定を確認してください。 [5] [6] [7] [8] [10] [11]