BIP 125 — オプトイン完全 Replace-by-Fee シグナリング - ビットコイン・インスティテュート

BIP: 125
  Layer: Applications
  Title: Opt-in Full Replace-by-Fee Signaling
  Authors: David A. Harding <dave@dtrt.org>
           Peter Todd <pete@petertodd.org>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125
  Status: Deployed
  Type: Specification
  Assigned: 2015-12-04
  License: PD

概要

今日の多くのノードは、同じインプットを使用する別のトランザクションによって、メンプール内のトランザクションを置換しない。このため、送金者は予期しない承認遅延に対処するためや、その他の有用な置換を行うために、既に送信したトランザクションを調整することが困難である。

ここで述べるオプトイン完全リプレイス・バイ・フィー (opt-in full-RBF) シグナリングポリシーは、送金者がトランザクションに対して、将来そのトランザクションを置換できるようにしたいことを示すシグナルを付加することを可能にする。このシグナルに応じて、以下が行われる。

ノードは、このシグナルを含むトランザクションをメンプール内で置換することを許可してよい。
このシグナルを含むトランザクションの受信者は、そのトランザクションが承認されるまで支払いとして扱わないことを選択してよく、これにより送金者が許可された置換を用いて受信者を欺くリスクが排除される。

ノードと受信者は、シグナルを持たないトランザクションについては従来どおりの扱いを継続してよく、既存の現状が維持される。

概要

本ポリシーは、トランザクションが置換可能であることをシグナリングする 2 つの方法を規定する。

明示シグナリング: トランザクションのインプットのいずれかが (0xffffffff - 1) 未満の nSequence 番号を持つ場合、そのトランザクション自身の置換許可にオプトインしたとみなされる。
継承シグナリング: 置換可能性を明示的にシグナリングしないトランザクションは、その祖先のいずれかが置換可能性をシグナリングしておりかつ未承認である限り、本ポリシーの下で置換可能である。

実装の詳細

Bitcoin Core 0.12.0 で予定される初期実装は、以下のルールを用いる。

メンプール内に現在ある 1 つまたは複数のトランザクション (オリジナルトランザクション) は、同一インプットの 1 つ以上を使用する新しいトランザクション (置換トランザクション) によって置換される。条件は以下のとおりである。

オリジナルトランザクションが、上記「概要」節に述べたとおり、明示的にまたは継承を通じて置換可能性をシグナリングしている。
置換トランザクションが未承認インプットを含めてよいのは、そのインプットがオリジナルトランザクションのいずれかに含まれていた場合に限る。(未承認インプットとは、現時点で未承認のトランザクションのアウトプットを使用するインプットを指す。)
置換トランザクションは、オリジナルトランザクションが支払った合計額以上の絶対手数料を支払う。
置換トランザクションは、ノードの最低リレー手数料設定で定められたレート以上で、自身の帯域分の手数料も支払わなければならない。たとえば、最低リレー手数料が 1 satoshi/byte で置換トランザクションの合計が 500 バイトであれば、置換は元のものの合計より少なくとも 500 satoshi 高い手数料を支払わなければならない。
置換されるオリジナルトランザクションの数と、メンプールから追い出される子孫トランザクションの数の合計は、100 トランザクションを超えてはならない。

初期実装は Bitcoin Core PR#6871 (https://github.com/bitcoin/bitcoin/pull/6871) で確認でき、具体的には master ブランチのコミット 5891f870d68d90408aa5ce5b597fb574f2d2cbca から 16a2f93629f75d182871f288f0396afe6cdc8504 まで (両端含む) である。

受信側ウォレットのポリシー

未承認トランザクションをユーザーに表示する、または未承認トランザクションに関するデータを自動化システムに提供するウォレットは、以下のいずれかを行うことを検討すべきである。

オプトイン full-RBF トランザクションに対する追加の警戒を、ユーザーまたはデータ利用者に伝える。
オプトイントランザクションを、承認されるまで無視する。

子孫トランザクションも継承シグナリングを通じて本ポリシーの下で置換可能になりうるため、オプトイン full-RBF トランザクションを処理する際に用いる手法は、祖先のオプトイン full-RBF トランザクションのいずれかが未承認である限り、すべての子孫トランザクションにも引き継がれるべきである。

送信側ウォレットのポリシー

置換可能性をシグナリングしたくないウォレットは、最大シーケンス番号 (0xffffffff) を用いるか、ロックタイムも用いたい場合はシーケンス番号 (0xffffffff-1) を用いるべきである。既知のウォレットは現在すべてこの運用を行っている。また、置換可能性を明示的にまたは継承シグナリングを通じてシグナリングしている未承認トランザクションを使用しないよう注意すべきである。ほとんどのウォレットは、自身が作成した未承認トランザクション以外の未承認トランザクションを使用しないことで、現在この運用を行っている。

置換を行いたいウォレットは、明示シグナリングを用い、上記「実装の詳細」節に述べた基準を満たすべきである。Bitcoin Wiki ページ (https://en.bitcoin.it/wiki/Transaction_replacement)が、ウォレット作者がトランザクション置換に関する展開済みメンプールポリシーを追跡できるよう作成されている。

初期実装は、拒否された置換に対して P2P プロトコルの reject メッセージを利用しており、これにより P2P クライアントは自身の置換がピアによって最初に受け入れられたかを判定できる。一部のピアに送信しつつ他のピアからのリレーを受信するという標準的な P2P 軽量クライアントの慣行により、クライアントは置換が伝搬したかを判定できるはずである。

動機

サトシ・ナカモトのオリジナルのビットコイン実装は、各インプットに nSequence 番号フィールドを設け、メンプール内でそのインプットを含むトランザクションの置換を許可していた (https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434)。置換を受け取った際、ノードはより低いシーケンス番号のインプットを持つトランザクションを、より高いシーケンス番号を持つトランザクションで置換することになっていた。

その実装では、置換トランザクションは追加手数料を支払う必要がなかったため、マイナーが置換を取り込む直接的な動機がなく、リレーノードの帯域使用過多を防ぐ組み込みのレート制限もなかった。ナカモトはビットコインバージョン 0.3.12 で置換を削除し (https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522)、「Disable replacement feature for now」というコメントだけを残した。

より高い手数料のトランザクションでトランザクションを置換することは、送金者が自身の意向をマイナーと一致させる方法を提供したが、置換を再有効化するリプレイス・バイ・フィー (RBF) パッチが利用可能になった頃には、最初に見たバージョンのトランザクションが承認される可能性が非常に高いと期待する受信者が現れていた。このため、置換は禁止すべきだと主張するユーザーもいた。

これらの懸念に対処するため、置換トランザクションがオリジナルトランザクションと同じ全アウトプットに対して同額以上を支払うことを要求する RBF の派生案が作られた。これは RBF First Seen Safe (RBF-FSS) と呼ばれ、元の RBF は full-RBF と呼ばれるようになった。RBF-FSS は最初に見たバージョンのトランザクションに依存する受信者にとっては受け入れやすかったが、使用するたびにトランザクションにインプットを追加する必要があり、結果として予備インプットを持たないウォレットは利用できなくなり、異なる出所のインプットが同一トランザクション内で使用されることによるプライバシー喪失や、トランザクションバイト数の無駄な増加が生じた。

オプトイン full-RBF は、ナカモトのオリジナルのセマンティクスを (ロックタイム利用者がオプトアウトできるよう僅かな調整を加えて) 用いて置換可能であることをシグナリングするものであり、最初に見たバージョンに依存するユーザーにそれらのトランザクションを無視する手段を提供しつつ、同時に full-RBF の効率上の利点も享受できるようにする。

オプトイン full-RBF と nSequence の他の用途との間に、既知の問題のある相互作用は存在しない。具体的には、オプトイン full-RBF は、ビットコイン 0.1 実装で提供されるコンセンサスにより強制されるロックタイム、BIP68 (コンセンサスにより強制されるシーケンス番号を用いた相対ロックタイム)、および BIP112 (CHECKSEQUENCEVERIFY) と互換性がある。

展開

現在、そしてビットコインの最初のリリース以降、ネットワークハッシュレートの 100% が、オプトイン full-RBF のセマンティクス (シーケンスが (0xffffffff - 1) 未満) を用いるトランザクションをマイニングしている。

ノードとマイナーの間でメンプールの既定の置換ポリシーとしてオプトイン full-RBF が普及することは、Bitcoin Core 0.12.0 (2016 年 1 月から 2 月にかけてのリリース予定) や Bitcoin LJR のような類似のノードソフトウェアへのアップグレードに伴って広がっていくものと予想される。

実際の置換は、以下の 2 つの条件が満たされるまでは信頼性に欠けるかもしれない。

置換をサポートするのに十分な数のノードがアップグレードされ、送信側ウォレットから相当量のハッシュレートを支配するマイナーへ置換を届けるリレー経路が提供されること。
置換をサポートするのに十分なハッシュレートがアップグレードされ、置換がマイニングされる合理的な確率が確保されること。

後方互換性

オプトイン RBF サポートが追加または提案された時点で、既定で nSequence を (0xffffffff - 1) 未満に設定してトランザクションを作成する既知のウォレットは存在しなかった。したがって、既定で置換可能性を明示的にシグナリングする既知のウォレットも存在しなかった。また、既定で他ユーザーの未承認トランザクションを使用する既知の主要ウォレットも存在しなかったため、継承された置換可能性をシグナリングする既知のウォレットも存在しなかった。

著作権

本文書はパブリックドメインに置かれる。

BIP 125 — オプトイン完全 Replace-by-Fee シグナリング

概要

概要

実装の詳細

受信側ウォレットのポリシー

送信側ウォレットのポリシー

動機

展開

後方互換性

関連項目

著作権

原典の外部ソース

他の外部ソース

概要

概要

実装の詳細

受信側ウォレットのポリシー

送信側ウォレットのポリシー

動機

展開

後方互換性

関連項目

著作権

関連エントリー

原典の外部ソース

他の外部ソース