Sparrow Wallet v2.4.2: v3トランザクション(TRUC)対応の意味

Sparrow Wallet v2.4.2: v3トランザクション(TRUC)対応の意味

Sparrow Wallet v2.4.2で、トランザクションエディタがnVersion=3のトランザクション(通称 TRUC: Topologically Restricted Until Confirmation)の読み込みに対応しました。一見地味なアップデートに見えますが、Bitcoinのメモリプール政策とLayer 2プロトコルの進化において重要な意味を持つ変更です。この記事では、TRUCトランザクションの技術的背景と、Sparrowがこれに対応したことの実用的な意義を掘り下げていきます。

トランザクションピンニングという問題

Bitcoinのメモリプールには、トランザクション置き換え(RBF: Replace-By-Fee)を制御するための複数のルールが存在します。BIP125で定義されたRBFルールでは、置き換えトランザクションは元のトランザクションよりも高い絶対手数料を支払わなければなりません(Rule 3)。また、置き換えによって追い出されるトランザクションの数にも上限があります(Rule 5)。

これらのルールの隙間を突くのがトランザクションピンニング攻撃です。Lightning Networkのようなオフチェーンプロトコルでは、チャネルの一方的クローズ時にコミットメントトランザクションをブロードキャストし、必要に応じてCPFP(Child Pays For Parent)で手数料を引き上げます。ここで悪意あるカウンターパーティが、巨大なサイズの低手数料子トランザクションを先に作成してしまうと、正当な手数料引き上げが経済的に極めて困難になります。

具体的には、攻撃者が100,000 vBの子トランザクションを1 sat/vBで作成した場合、Rule 3により置き換えには少なくとも100,000 sats以上の追加手数料が必要になります。正当なユーザーの手数料引き上げが事実上ブロックされてしまうわけです。

BIP431: TRUCトランザクションの設計

BIP431はこの問題に対する解決策として、nVersion=3を使ったオプトイン型のトポロジー制限を定義しています。主要なルールは以下の通りです。

ルール1: 暗黙的RBFシグナリング。 TRUCトランザクションはBIP125のシーケンス番号によるシグナリングがなくても、常に置き換え可能として扱われます。

ルール2: バージョン伝播。 未確認のTRUCトランザクションの祖先・子孫はすべてTRUCでなければなりません。確認済みトランザクションとの間にはこの制約はありません。

ルール3: トポロジー制限。 未確認のTRUCトランザクションは、未確認の祖先を最大1つ、未確認の子孫を最大1つしか持てません。つまり「親1 → 子1」の線形トポロジーのみが許可されます。

ルール4: 子トランザクションのサイズ制限。 未確認のTRUC祖先を持つTRUCトランザクション(つまり子)は、sigop調整後の仮想サイズが1,000 vB以下でなければなりません。

この設計により、置き換えに必要な追加手数料の上限が大幅に下がります。子トランザクションが最大1,000 vBに制限されるため、最悪でも1,000 sats程度(1 sat/vB時)の追加コストで置き換えが可能です。従来の100倍の改善になります。

Bitcoin Coreのコードでは、v28.0でnVersion=3がstandardとして有効化されました。該当する変更の核心は TX_MAX_STANDARD_VERSION の引き上げにあります(PR #29496)。

// src/policy/policy.h
// https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h
static constexpr decltype(CTransaction::version) TX_MAX_STANDARD_VERSION{3};

この定数を2から3に変更することで、nVersion=3のトランザクションがネットワーク上でリレーされるようになりました。TRUCポリシーの判定ロジックに使われる定数群は、src/policy/truc_policy.h で以下のように定義されています。

// src/policy/truc_policy.h
// https://github.com/bitcoin/bitcoin/blob/master/src/policy/truc_policy.h

/** Check if this transaction is a TRUC transaction. */
static inline bool IsTruc(const CTransaction& tx)
{
    return tx.version == TRUC_VERSION;
}

static constexpr decltype(CTransaction::version) TRUC_VERSION{3};

/** Maximum number of transactions including a TRUC tx and all of its ancestors. */
static constexpr unsigned int TRUC_ANCESTOR_LIMIT{2};

/** Maximum number of transactions including a TRUC tx and all of its descendants. */
static constexpr unsigned int TRUC_DESCENDANT_LIMIT{2};

/** Maximum sigop-adjusted virtual size of a tx which has a TRUC unconfirmed ancestor. */
static constexpr int64_t TRUC_CHILD_MAX_VSIZE{1000};

メモリプール検証時には、src/validation.cppPackageTRUCChecks() が呼び出され、上記の制約に違反するトランザクションは "TRUC-violation" として拒否されます。

Sparrowのトランザクションエディタとv3対応

Sparrow Walletの特徴の一つは、フル機能のトランザクションエディタを備えている点です。単にトランザクションを送受信するだけでなく、PSBTの全フィールドを検査し、バイトレベルでトランザクション構造を確認できます。これはブロックチェーンエクスプローラとしても機能します。

v2.4.2以前のSparrowでは、nVersion=3のトランザクションをファイルやQRコードから読み込もうとすると、バリデーションエラーが発生する可能性がありました。Sparrowの基盤ライブラリであるDrongoでは、トランザクションのパース時にバージョンフィールドの妥当性チェックが行われるためです。

v2.4.2でこの制限が緩和され、nVersion=3のトランザクションを正しくパース・表示できるようになりました。これにより以下のことが可能になります。

Lightning関連トランザクションの検査。 Bitcoin Core v28以降のノードでは、LNの新しいコミットメントトランザクション形式がTRUC + Ephemeral Anchorsを使用します。これらのトランザクションがオンチェーンに現れた際に、Sparrowのトランザクションエディタで構造を詳しく調べることができます。

PSBT内のv3トランザクション処理。 Sparrow v2.4.0でPSBTv2をデフォルトの内部表現に採用したことと合わせて、TRUCトランザクションを含むPSBTの読み込み・署名ワークフローが完全にサポートされます。

手数料引き上げ操作の理解。 TRUCトランザクションの子トランザクション(1,000 vB以下のCPFP)がどのように構成されているかを視覚的に確認できます。Sparrowのトランザクションダイアグラムで、入力・出力の構造とサイズ制約の関係を把握しやすくなります。

Ephemeral Anchorsとの関係

TRUCトランザクションの主要なユースケースの一つがEphemeral Anchorsです。これはLNコミットメントトランザクションに0値のOP_TRUE出力(Pay-to-Anchor、P2A)を付加し、どちらのチャネルパーティでもCPFPで手数料を追加できる仕組みです。

Sparrow v2.2.0で既にP2A出力の送信・表示に対応していましたが、v2.4.2でv3トランザクション自体の読み込みに対応したことで、TRUCトランザクション + P2Aの組み合わせを含むトランザクショングラフ全体をSparrow上で追跡できるようになりました。

今後の展望

現時点でSparrowはTRUCトランザクションの「読み込みと表示」に対応した段階です。一般的なウォレットユーザーが直接nVersion=3でトランザクションを作成するケースは限られますが、LNノードオペレーターやプロトコル開発者にとっては、デバッグやトランザクション分析の重要なツールとなります。

なお、Bitcoin Core v30.0では、ウォレットレベルでもTRUCトランザクションの作成・支出がサポートされました。今後はSparrowでもTRUCトランザクションの作成機能が追加される可能性があります。

Bitcoin Coreでは既にCluster Mempoolの開発が進んでおり、TRUCトランザクションのルールはさらに進化する可能性があります。Sparrowのトランザクションエディタがこうしたプロトコルレベルの変化にいち早く対応していることは、単なるウォレットを超えたBitcoin開発ツールとしての立場を明確にしています。


Sparrow Wallet v2.4.2は2026年3月10日にリリースされました。ダウンロードは sparrowwallet.com/download から。

この続き : 0字 / 画像 0枚
100

会員登録 / ログインして続きを読む

関連記事

記事を書いた人

SNSにシェア

このクリエイターの人気記事

ビットコインに「利回り」が必要ない理由

540

Base58 開発者ワークショップ参加記録メモ - 2024年9月20日

168

ビットコインマイニングを分散化するOcean MiningのDATUMプロトコル

106