今週のニュースレターでは、LNに影響を与えるBitcoin Coreのブロック遅延バグの開示と、 提案中のバージョン3トランザクショントポロジーの制限と互換性のある新しいゼロ承認チャネルを 安全に開設する方法についての懸念、外部の参加者にトランザクションのインプットの提供を許可する際に 多くのコントラクトプロトコルが従わなければならないルールの説明、 トランザクションPinningを回避するための新しいトランザクション置換ルールの提案に関する複数の議論および Bitcoin-Devメーリングリストの簡単なアップデートを掲載しています。

ニュース

  • ● LNに影響するBitcoin Coreのブロック遅延バグの公開: Eugene Siegelは、約3年前に責任を持って開示した Bitcoin CoreのバグをDelving Bitcoinで発表しました。 Bitcoin Core 22以降では、このバグの修正が含まれていますが、 まだ多くのユーザーが影響を受けるバージョンを実行しており、 そのユーザーの中には、バグの悪用に対して脆弱になる可能性がある LNの実装や他のコントラクトプロトコルのソフトウェアを実行している可能性もあり、 Bitcoin Core 22以降にアップグレードすることを強く推奨します。 私たちの知る限り、以下に説明する攻撃により資金を失った人はいません。

    攻撃者は、22より前のバージョンのBitcoin Coreを実行しているリレーBitcoinノードに関連付けられている LN転送ノードを見つけます。攻撃者は、被害者のBitcoinノードに多数の個別の接続を開きます。 次に、新しく発見されたブロックを、他のどの誠実なピアよりも速く被害者に配信しようと試み、 その結果、被害者のノードは、攻撃者の管理下のピアを、 被害者の高帯域幅のコンパクトブロックリレースロットのすべてに自動的に割り当てます。

    攻撃者が、被害者のBitcoinのピアスロットの多くを制御できるようになると、 被害者の両側で管理下にあるチャネルを使って、自分が作成した支払いを転送します。たとえば、

    攻撃者（支払人） -> 被害者による転送 -> 攻撃者（受取人）

    攻撃者はマイナーと協力して、未承認状態のトランザクションをリレーすることなく チャネルの受信側を一方的に閉じるブロックを作成します（マイナーの支援が必要なのは、 mempoolのトランザクションを監視するLN実装を攻撃する場合のみです）。 そのブロックや、マイナーによって作成された別のブロックも、 HTLCのプリイメージをリリースすることで支払いを請求します。 通常であれば、被害者のBitcoinノードはそのブロックを確認し、 ブロックをLNノードに渡し、LNノードはプリイメージを抽出することで、 転送のバランスを保ちながら、支払人側の支払額を請求することができます。

    しかし、この場合、攻撃者はBitcoin Coreノードがプリイメージを含むブロックを確認することを防ぐために 今回開示されたブロック遅延攻撃を使用します。この遅延攻撃は、旧バージョンのBitcoin Coreが、 ピアがアナウンスしたブロックを配信するまで最大10分間待機してから、別のピアにそのブロックを要求することを利用します。 ブロック間隔の平均が10分であるとすると、x 個の接続を制御する攻撃者は、 x 個のブロックを生成するのにかかる時間とほぼ同じ時間、 Bitcoinノードのブロックの受信を遅らせることができることを意味します。 転送された支払いを40ブロック以内に請求する必要がある場合、 50個の接続を制御する攻撃者は、支払いノードが支払いの払い戻しを受け取ることができるようになるまで、 Bitcoinノードがプリイメージを含むブロックを確認できないようにする十分な可能性があります。 その場合、攻撃者の支払いノードは何も支払わず、攻撃者の受信ノードは被害者のノードから抽出された金額を受け取ることになります。

    Siegelの報告によると、Bitcoin Coreにはこの遅延を防ぐための2つの変更が加えられています:

    • ● Bitcoin Core #22144では、メッセージ処理スレッドでピアが処理される順序をランダム化します。 ニュースレター #154を参照ください。

    • ● Bitcoin Core #22147では、インバウンドピアのパフォーマンスが向上しているように見えても、 少なくとも1つのアウトバウンドの高帯域幅コンパクトブロックピアを保持します。 ローカルノードが、そのアウトバウンドピアを選択するのは、 攻撃者の管理下に置かれている可能性が低いためです。そのため、 安全のためにアウトバウンドピアを少なくとも１つ保持するのは有益です。

  • ● v3トランザクションでゼロ承認チャネルを安全に開く: Matt Coralloは、提案中のv3トランザクションリレーポリシーが使用される際に、 安全にゼロ承認チャネルを開設する方法について、 Delving Bitcoinに投稿しました。 ゼロ承認チャネルは、資金提供者が初期資金の一部またはすべてを受入人に提供する新しいシングルファンドチャネルです。 これらの資金は、チャネル開設トランザクションが十分な数の承認を得るまでは安全ではないものの、 受入人が標準的なLNプロトコルを使用して資金提供者を通じて資金を使用するのにリスクはありません。 v3トランザクションリレーのポリシーの初期提案では、 未承認のv3トランザクションは最大1つの子トランザクションしかmempoolに持つことはできません。 必要に応じて、1つの子トランザクションがCPFPにより親の手数料を引き上げることが期待されます。

    このv3ルールは、両参加者がゼロ承認チャネルの開設のために手数料を引き上げられるようにすることと互換性がありません。 チャネルを開設するファンディングトランザクションは、チャネルを閉じるv3トランザクションの親であり、 手数料の引き上げを行うv3トランザクションの祖父母です。 v3トランザクションでは1つの親と1つの子しか認められていないので、 ファンディングトランザクションの作成方法を変更しない限り、手数料を引き上げる方法はありません。 Bastien Teinturierは、スプライシングにも同様の問題があると指摘しています。

    この記事を書いている時点では、提案されている主な解決策は、 CPFPの手数料引き上げ用の追加のアウトプットを含むように ファンディングトランザクションとスプライシングトランザクションを変更することで、 クラスターmempoolがv3により寛容なトポロジー（つまり、 1つだけの親ではなく、子が1つだけ）を許可するようになるのを待ち、 その後、より寛容なトポロジーを使用することを優先して追加のアウトプットを削除することであるようです。

  • ● txidの展性に対して脆弱なプロトコルでインプットがsegwitを使用していることを検証する要件: Bastien Teinturierは、第三者がトランザクションにインプットを提供するプロトコルについて、 別のユーザーがそのトランザクションに署名を提供した後でtxidが変更されてはならない、 見過ごしやすい要件の説明をDelving Bitcoinに投稿しました。 たとえば、LNのアリスとボブがデュアルファンドチャネルを開設する場合、 両者がインプットを提供できます。もし一方の参加者が後で提供に失敗した場合、 それぞれに払い戻しが行われることを保証するために、 ファンディングトランザクションを使用する払い戻しトランザクションを作成し署名し、 必要な場合を除いてオフチェーンで保管します。両者が払い戻しトランザクションに署名したら、 両者は安全に親のファンディングトランザクションに署名してブロードキャストすることができます。 子の払い戻しトランザクションは予想されるtxidを持つ親のファンディングトランザクションに依存するため、 このプロセスはtxidの展性のリスクがない場合にのみ安全です。

    segwitは、txidの展性を防止しますが、これはトランザクションのインプットが segwitアウトプットを使用している場合に限ります。 segwit v0の場合、ボブがsegwit v0アウトプットを使用していることをアリスが確認する唯一の方法は、 ボブのアウトプットを含む前のトランザクションの全体のコピーを入手することです。 アリスがこのチェックを実行しない場合、ボブはsegwitアウトプットを使用していると嘘を付くことができ、 代わりにtxidを変更可能なレガシーアウトプットを使用して、払い戻しトランザクションを無効にし、 アリスが身代金を支払うことに同意しない限り資金の返還を拒否することができます。

    segwit v1（taproot）では、各SIGHASH_ALL署名は、 トランザクションで使用される以前のすべてのアウトプットに直接コミットするため（ニュースレター #97参照）、 アリスはボブにscriptPubKey（ボブが共有トランザクションを作成するために開示する必要がある他の情報からどのみち知ることが可能）の開示を要求できます。 アリスは、scriptPubKeyがsegwit（v0またはv0のいずれか）を使用していることを検証し、 それに自分の署名をコミットさせます。ここで、ボブが嘘をついていて実際にはsegwitではないアウトプットであった場合、 アリスの署名によって作られたコミットメントは有効ではないので、署名は無効で、 ファンディングトランザクションは承認されず、払い戻しの必要もありません。

    このことは、事前署名される払い戻しに依存するプロトコルが安全性のために従わなければならない2つのルールにつながります:

    1. インプットを提供する場合、segwit v1アウトプットを使用するようにし、 トランザクション内の他のすべての支払いに使用される以前のアウトプットを入手し、 それらがすべてsegwitのscriptPubKeyを使用していることを検証し、 署名を使用してそれらにコミットします。

    2. インプットを提供していないか、segwit v1アウトプットを使用しない場合は、 すべてのインプットについて以前の完全なトランザクションを入手し、 トランザクションで使用されるそれらのアウトプットがすべてsegwitアウトプットであることを検証し、 署名を使用してそれらのトランザクションにコミットします。 すべてのケースにおいて、この2つめの手順を使用することもできますが、 最悪の場合、1つめの手続きのほぼ20,000倍の帯域幅を消費することになります。

  • ● Pinningを回避するための手数料率の置換の提案: Peter Toddは、 既存のRBF（Replace-by-Fee）ポリシーがトランザクションの置換を許可しない場合でも使用可能な トランザクション置換ポリシーのセットの提案をBitcoin-Devメーリングリストに投稿しました。 彼の提案には2つの異なるバリエーションがあります:

    • ● 純粋な手数料率による置換(pure RBFr): 現在mempoolにあるトランザクションは、 かなり高い手数料率を支払う競合トランザクションと置換できる（たとえば、 2倍の手数料率を支払うトランザクション）

    • ● 手数料率によるワンショットの置換(one-shot RBFr): 現在mempoolにあるトランザクションを、 置換の手数料率も十分に高い場合（mempoolの上位1,000,000 vbyteに入るくらい）に限り 僅かに高い手数料率（たとえば1.25倍）を支払う競合トランザクションと置換できる。 （つまり、置換が受け入れられた直後にブロックが生成された場合、それがマイニングされることを意味する）

    Mark Erhardtは、提案されたポリシーが悪用されることで、 攻撃者が最小限のコストで無限のノード帯域幅を消費することが可能になることを説明しました（1、 2）。Peter Toddは、その特定の悪用を排除するためにポリシーを更新しましたが、 他の懸念がGregory SandersとGloria ZhaoによってDelving Bitcoinのスレッドで提起されました:

    • 「クラスターmempool以前では、このようなことを推論することは非常に難しいことです。 Peterのアイディアの最初のイテレーションは、無制限のフリーリレーを可能にする壊れたものでした。 彼は、RBFの制限を追加してホットパッチを当てることでそれを修正したと主張していますが、 いつものように、現在のRBFルールについて推論するのは非常に難しく、おそらく不可能でしょう。 私は、フリーリレーの保護のアイディアを完全に諦める前に、 RBFのインセンティブを正しくすることにエネルギーをフォーカスした方が良いと思います。」—Sanders

    • 「現在存在するmempoolは、クラスターサイズが制限されていないため、 マイナースコアやインセンティブの互換性を計算する効率的な方法をサポートしていません。[…] クラスターmempoolの利点の1つは、mempool全体でマイナースコアやインセンティブ互換性のようなものを計算できることです。 同様にv3の利点は、トポロジーが制限されているため、クラスターmempoolよりも前にそれを実行できることです。 クラスターmempoolの設計と実装にみんなが挑戦する前に、私はv3をクラスター制限を実装せずに、 「クラスター制限」として位置づけていました。それが既存のパッケージ制限（先祖=2、子孫=2、3まで上げると再び無限のクラスターになります） を使用してクラスター制限（count = 2）を具体化する唯一の方法だからです。 v3のもう1つの利点は、クラスターmempoolのブロックを解除できることで、これは簡単なことだと私は考えています。 まとめると、手数料率によるワンショットの置換の提案は機能しないと思います（つまり、 フリーリレーの問題がなく、正確に実装することが可能です）。」—Zhao

    この記事の執筆時点では、個別の議論はまとまっていません。Peter Toddは、 手数料率ルールによる置換の実験的な実装をリリースしました。

  • ● Bitcoin-Devメーリングリストの移行に関するアップデート: この記事の執筆時点で、 Bitcoin-Devメーリングリストは、別のサーバーへの移行プロセスの一環として（ニュースレター #276参照）、 新しいメールを受け付けていません。移行が完了したらOptechはアップデートを提供します。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

  • ● LND v0.17.4-betaは、この人気のLNノード実装のメンテナンスリリースです。 リリースノートにあるように、「これは、次の複数のバグを修正するホットフィックスリリースです。 再起動するまでチャネル開設がハングする。bitcoindのポーリングモード使用時のメモリリーク。 プルーニングノードで同期が失われる。TLS証明書の暗号化がオンになっているとRESTプロキシが動作しない。」

注目すべきコードとドキュメントの変更

今週のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #29189は、libconsensusを廃止します。 libconsensusは、Bitcoin Coreのコンセンサスロジックを他のソフトウェアで使えるようにする試みでした。 しかし、このライブラリはあまり普及しておらず、Bitcoin Coreのメンテナンスの負担になっています。 計画は、「CMakeには移行せず、v27で終了する。残ったユースケースは将来libbitcoinkernelで処理できるだろう。」 となっています。

  • ● Bitcoin Core #28956は、Bitcoin Coreから調整時間を削除し、 コンピューターの時計がネットワークの他の部分と同期していないように見える場合はユーザーに警告します。 調整時間は、ピアから報告された時刻に基づいてローカルノードの時刻を自動的に調整するものでした。 これによって、わずかに時計が正しくないノードがピアから学ぶことができ、不必要にブロックを拒否することを回避し、 生成したブロックにより正確な時間を与えることもできます。しかし、調整時間は過去にも問題を引き起こしており、 現在のネットワーク上のノードに有意義な利点をもたらしません。このPRについて以前掲載した内容については、 ニュースレター #284をご覧ください。

  • ● Bitcoin Core #29347は、デフォルトでv2 P2Pトランスポートを有効にします。 v2プロトコルをサポートする2つのピア間の新しい接続は暗号化されます。

  • ● Core Lightning #6985は、オンチェーンウォレットの秘密鍵を 他のウォレットにインポートできる方法で返せるようにするオプションをhsmtoolに追加しました。

  • ● Core Lightning #6904では、CLNの接続とゴシップの管理コードにさまざまなアップデートが行われました。 ユーザーの目に見える変更としては、ピアがローカルノードと最後に安定した接続を1分以上保ったタイミングを示すフィールドが追加されました。 これにより、接続が不安定なピアを削除することができます。

  • ● Core Lightning #7022は、Core Lightningのテストインフラからlnprototestを削除しました。 これが追加された際の説明はニュースレター #145をご覧ください。

  • ● Core Lightning #6936は、非推奨のCLN機能を支援するインフラを追加しました。現在のプログラムのバージョンに基づき、 デフォルトでそれらの機能を自動的に無効にする関数を使用するコード内の機能は非推奨になりました。 ユーザーはコードがまだ存在している限り、指定された非推奨バージョンの後でも機能を強制的に有効にできます。 これにより、CLNの機能が非推奨として報告されているものの、削除が計画された後も長期間デフォルトで機能し続け、 ユーザーがその機能に依存し続けて実際の削除がより困難になるという時折発生する問題を回避することができます。

  • ● LND #8345では、トランザクションをブロードキャストする前に、 利用可能な場合にフルノードのtestmempoolaccept RPCを呼び出すことで、 トランザクションがリレーされる可能性があるかどうかのテストを行うようになりました。 これにより、ノードは第三者に何かが送信される前にトランザクションに関する潜在的な問題を検出できるため、 問題の発見を早め、バグによる潜在的な被害を抑えることができます。 testmempoolaccept RPCは、Bitcoin Coreや ほとんどの最新のBitcoin Coreのソフトウェアフォークおよびbtcdフルノードで利用可能です。