Develop with pleasure!

福岡でCloudとかBlockchainとか。

v3トランザクションリレー

最近Bitcoin Coreにv3トランザクションリレーポリシーのPRがマージされたので↓

github.com

v3トランザクションリレーについてまとめてみた。

トランザクションの手数料引き上げ方法と課題

Bitcoinでブロードキャスト済みのトランザクションの手数料を引き上げる方法は、主に以下の2つ。

制限とPinning攻撃

RBFやCPFPのような手数料を引き上げる仕組みは用意されているものの、無条件に実行できるとネットワークに対するDoS攻撃が可能になるため、それぞれ制限が設けられている。主な制限は、

  • BIP125 RBFルール:
  • 最大パッケージサイズの制限:
    CPFPを行う場合、mempool内に101KvBを超える子孫持つ場合、または25個を超える子孫/祖先を持つようなトランザクションはCPFPできない。

LNなどのマルチパーティコントラクトでは、上記の制限を悪用して低手数料のトランザクションをずっとmempoolに留めさせようとするPinning攻撃が問題になる。

RBFのルール3については、攻撃者は高手数料だがサイズが大きく手数料率は低い置換トランザクションを作成する。この場合、手数料率は低いのでマイニングされづらいが、誠実な相手がさらにそのトランザクションを置換しようとすると、高額な手数料の支払いが必要になる。誠実なユーザーのトランザクションがマイニングされると置換により攻撃者のコスト負担はゼロになり、誠実なユーザーのみが高額な手数料を負担した結果だけが残る。

ルール5については、子孫トランザクションも含まれるため、Pinningしたいトランザクションに多数の子トランザクションを作成することで、置換を困難にする。

CPFPの場合は、攻撃者が先に制限に達する大量の子トランザクションを作成することで(もしくはサイズ制限を超えるような)、それ以上CPFPできなくする。

このようなPinning攻撃は、タイムロックなどの条件が設定されているマルチパーティプロトコルにとっては厄介な問題になる。LNのような二者間のプロトコルにおいては、Bitcoin Core v0.19.0で追加されたCPFP carve outというポリシーによって、CPFPにおいて上記制限を超える場合も例外的に子の追加が可能になり、これを利用してPinning攻撃への対策を行ったアンカーアウトプットを導入している*1

techmedia-think.hatenablog.com

このような状況から、マルチパーティプロトコルではRBFではなくCPFP carve outベースの手数料の引き上げを採用している。

v3トランザクション

上記のようなPinning攻撃を回避して手数料の引き上げをより堅牢にするために提案されているのがv3トランザクションリレー。

これまでトランザクションのバージョンは、デフォルトのバージョン1と、OP_CSVのタイムロック機能を利用可能にするバージョン2が利用可能だったけど、今回導入した新しいリレーポリシーを利用可能にするのがバージョン3になる。

ただ、v3はトランザクションのあくまでBitcoin Coreのリレーポリシーに関する仕様であって、コンセンサスルールではない。v3トランザクションは、v2トランザクションと同じコンセンサスルールで評価される。

v3ルール

具体的には、バージョン3のトランザクションには以下のルールが適用される。

  1. BIP-125の置換可能性のシグナリングをしていない場合でも置換可能なトランザクションとして扱われる。
  2. 未承認のv3トランザクションの子孫について、子孫もv3トランザクションである必要がある(承認済みのv3トランザクションの子はv3でなくても良い)。
  3. v3トランザクションは未承認の祖先はすべてv3トランザクションである必要がある。
  4. v3トランザクションは複数の未承認の子孫を持つことはできない。なお、CPFP carve outポリシーはv3トランザクションには適用されない。
  5. v3トランザクションは複数の未承認の祖先を持つことはできない。
  6. 未承認のv3の祖先を持つv3トランザクションは、sigops調整後のトランザクションサイズが1000vB以下であること。
  7. 個々のv3トランザクションについて、パッケージ*2としての手数料率の要件を満たす場合、最小リレー手数料率を下回ることができる。

この結果、mempool内にあるv3トランザクションは子トランザクションを1つだけ持つことができ、v3子トランザクションは未承認の親を1つだけ持つことできる。そして、親子トランザクションはいずれもRBFによる置換が可能。その際、親子トランザクションの数の制限と、子トランザクションのサイズ制限により、RBFのルール3,5を悪用したPinning攻撃を回避できる。

v3リレーが可能になると、マルチパーティプロトコルでもRBFが利用可能になるため、LNの仕様変更も検討されている↓

https://bitcoinops.org/ja/newsletters/2024/01/24/#v3-ln

*1:carve outの例外は、参加者が2人より多いマルチパーティプロトコルでは機能しない。

*2:親子関係のあるトランザクションの順序付きリスト。通常は、トランザクション単体をネットワークにブロードキャストするけど、未承認の親子トランザクションを一緒にブロードキャストしたい場合に、それらをパッケージとしてブロードキャストできるようにしようという現在開発中の機能。どうしてパッケージが必要になるかというと、たとえばLNで、チャネルを閉鎖するのにコミットメントトランザクションをブロードキャストしようとするものの、手数料率が向上し、コミットメントトランザクション作成時の手数料ではmempoolに入らないような場合。CPFPで手数料上げようにも対象の親がmempoolに入らないことには使えないといった状況が起こる。そのため、高手数料な子と親を一緒にリレーできるパッケージのような仕組みが必要になる。