今週のニュースレターでは、いくつかのLN実装で最近修正された脆弱性と、 Taprootの機能を利用するためにLNプロトコルをアップグレードすることで複数のメリットを提供する提案の要約を掲載しています。 また、最近のBitcoin Core PR Review Clubミーティングの概要や、 Taprootの準備に関する情報、新しいソフトウェアリリースとリリース候補のリスト、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● LNの支払いが手数料に使われるCVE: 先週、Antoine Riardは、 複数のプログラムに対するCVEの発表をLightning-Devメーリングリストに投稿しました。 Bitcoinのユーザーは、使用する際に価値の大部分がコストとなるような 経済合理性のないアウトプットを作成することを常に控えてきました。 しかし、LNではユーザーが、オンチェーンでは経済合理性のない少額の送金を行うことができます。 そのような場合、支払いノードやルーティングノードは、コミットメントトランザクションのマイナー手数料を少額だけ過剰に支払い、 コミットメントトランザクションが公開された場合（ほとんどの場合、発生しませんが）事実上、 そのお金はマイナーに寄付することになります。

    Riardが報告したように、LNの実装では、経済合理性の制限をチャネルの資金の20%以上に設定できるため、 5回以下の支払いで、チャネルの資金のすべてをマイナーへの寄付に使用することができます。 マイナーに資金を奪われることは、LNで採用されている少額決済の仕組みの基本的なリスクですが、 わずか5回の支払いでチャネルの資金すべてを失うリスクは明らかに過剰であると考えられました。

    Riardのメールでは、一定額以上の資金をマイナーの手数料へ寄付するリスクのある支払いのルーティングを単純に拒否するなど、 いくつかの緩和策が記載されています。これを実装することで、実際に問題が発生するかどうかは不明ですが、 オンチェーン上で経済合理性のない少額の支払いを同時に複数回ルーティングするノードの能力が低下する可能性があります。 Optechが追跡している影響を受けたLNの実装はすべて、緩和策の少なくとも１つを実装したバージョンをリリースしているか、 近日中にリリースする予定です。

  • ● 複数のLNの改善案: Anthony Townsは、 支払いのレイテンシーを短縮し、バックアップの復元性を向上させ、 署名鍵がオフラインでもLN支払いを受け入れられるようにする方法を説明した サンプルコードを含む詳細な提案をLightning-Devメーリングリストに投稿しました。 この提案は、eltooと同様の利点を提供しますが、 ブロック高709,632で有効になるTaprootのソフトフォーク以外の、 SIGHASH_ANYPREVOUTや他のコンセンサスの変更を必要としません。 そのため、LN開発者によって実装、テストされたら、すぐにデプロイできます。 主な機能をみてみましょう:

    • ● 支払いのレイテンシーの短縮: 支払いのプロセスには必要なものの、支払いの詳細には固有ではない一部の詳細情報をチャネルパートナーが事前に交換しておくことで、 ノードは支払いと支払いに対する署名をチャネルパートナーに送信するだけで、 支払いを開始またはルーティングすることができます。 クリティカルパス上でのラウンドトリップの通信は不要であり、 LNノード間の基盤となるリンク速度に近い速度で支払いをネットワーク全体に伝播できます。 支払いが失敗した場合の払い戻しには時間がかかりますが、この変更前よりも遅くなることはありません。 この機能は、開発者のZmnSCPxjによって以前提案されたアイディア（ニュースレター #152参照）を拡張したもので、 同氏は今週、Townsとの議論のいくつかに基づいて関連する投稿を書きました。

    • ● バックアップの復元性の向上: 現在LNは、資金が盗まれる場合に備えて、チャネルの両参加者とWatchtowerは、 チャネルの過去のステートに関する情報を保存する必要があります。 Townsの提案では、チャネルのステートに関するほとんどの情報を決定論的に導出し、 各トランザクションにステート番号をエンコードすることで、必要な情報を復元できるようにしています （場合によって、多少のブルートフォースによる処理が必要になります）。 これにより、ノードはチャネル作成時にすべての鍵関連の情報をバックアップすることができます。 その他に必要な情報は、（盗難の場合は）ブロックチェーンから、 または（ノードが自身のデータを失った場合は）チャネルパートナーから入手できる必要があります。

    • ● 鍵がオフラインのまま支払いを受信: LNで支払いを送信またはルーティングするためには、基本的にオンライン（ホット）鍵が必要ですが、 現在のプロトコルでは、支払いを受信するのにもオンラインの鍵を必要とします。 Lloyd FournierによるZmnSCPxjの以前のアイディアに基づいて（ニュースレター #152でも取り上げています）、 受信ノードは、チャネルを開いたり、閉じたり、リバランスしたりするために鍵をオンラインにするだけで済みます。 これにより、マーチャントノードのセキュリティが向上します。

    この提案は、TaprootやPTLCを使用するようLNをアップグレードすることで、 よく知られているプライバシーと効率の利点も提供します。 このアイディアは、メーリングリストでよく議論され、この記事を書いている時点でも議論は続いています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Extract RBF logic into policy/rbfは、 Gloria ZhaoによるPRで、Bitcoin CoreのReplace By Feeロジックを個別のユーティリティ関数に抽出するものです。

  • mempoolの高レベルの設計目標は何ですか？

    mempoolは、非マイニングノードであっても、 マイニングのための最もインセンティブのあるトランザクション候補を維持することを目的としています。 しかし、DoS対策（例えば、P2Pネットワークを使って承認されないトランザクションのブロードキャストを許可しないなど）と、 マイナーのインセンティブ（mempoolの上位1ブロック分の手数料を最大化すること）との間には根本的な競合があります。 設計の目標は、競合がどこで発生するかを特定し、それを最小化しようとすることです。 ➚

  • RBFのロジックを個別のヘルパー関数に抽出することの利点は何ですか？

    ロジックを小さな関数に分離することで、単体テストが改善され、 mempoolのパッケージ受け入れやパッケージリレーの実装でロジックを再利用することができます。 ➚

  • BIP125のルール#2で、置換トランザクションが新しい未承認のインプットを導入しないことが重要な理由は何ですか？

    置換トランザクションで新しい 未承認 のインプットの追加を許可すると、 手数料率が増加しても、そのトランザクションの祖先の手数料率を減少させることができます。 マイナーは祖先の手数料率に基づいてブロックに含めるトランザクションを選択するため、 新しいインプットの追加を許可した場合、置換トランザクションは置換されたものよりもマイニングの魅力が低下する可能性があります。 ➚

  • BIP125のルール#4の、トランザクションが「自分の帯域幅を支払う」とはどういう意味ですか？ より高い手数料率を持つのであれば、どのような置換トランザクションでも許可していいのでは？

    「自分の帯域幅を支払う」とは、置換トランザクションが最小リレー手数料をカバーする追加金額を含む手数料を支払うことを意味します。 このルールがないと、悪意あるアクターはトランザクション手数料を1 satoshiずつ繰り返し引き上げ、 不釣り合いな量のmempoolのコンピューティングリソースと、ネットワーク帯域幅を使用することができます。 ➚

  • Replace-by-feeのロジックは、mempoolポリシーに関係しています。なぜこのロジックは、 ポリシールールではなく、コンセンサスルールにより置換トランザクションが失敗したと返すのですか？

    このロジックは、置換トランザクションが置換したトランザクションを支払いに使用しているケースをキャッチします。 元のトランザクションと置換トランザクションの両方を承認することは不可能であるため、 この置換トランザクションはブロックチェーンに現れることはなく、コンセンサスは無効です。 ➚

Taprootの準備 #17: 協力は常にオプション？

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

Gregory Maxwellによる最初の最初のTaprootの提案は、 コントラクト設計の興味深い原則を示唆していました:

“興味深いScriptには、ほとんどの場合、論理的なトップレベルの分岐があり、 参加者全員による署名だけでコントラクトを成立させることができます。 他の分岐は、ある参加者が協力できない場合にのみ使用されます。 もっと強く言うと、固定の有限の参加者が前もって設定されている 任意の コントラクトは、 N-of-Nと、より複雑なコントラクトを表現したい場合のOR条件として表現することができ、 またそうすべきであると考えています。” (強調は原文のまま)

それ以来、専門家はこの原則の普遍性について議論してきましたが、 私たちの知る限り、タイムロックにフォーカスした2つの例外があります:

  • ● コンセンサスによるセルフコントロールの強化: タイムロックを利用して、一定期間、自分のビットコインを使わないようにしている人もいます。 タイムロックの要件は、署名以上のものが必要であることを示唆ししているように思えますが、 いくつかの批判があります:

    • タイムロックされたビットコインをどうしても使いたい人は、 おそらく他の資産を担保にしてローンを組むことができます。 これは、このセルフコントラクトの有用性を損ないます。

    • コンセンサスによるscriptpathのタイムロックに加えて、 ユーザーは自分の鍵とタイムロックの期限が切れた時にのみ署名する第三者の鍵とでkeypathによる支払いを可能にできます。 これは、より効率的なだけでなく、受け取ったフォークコインを販売したり、 人生の大きな変化や価格上昇などにより早期の使用を許可する第三者と協力するなど、 より柔軟な支払いポリシーを実装することができます。

  • ● Vault: 数週間前の本サイトのAntoine Poinsotのコラムで言及されているように、 Vaultも資金保護のためにタイムロックを多用していますが、 「ほとんどのコントラクトには参加者全員が署名に協力するハッピーパスがあるというTaprootの洞察とは対照的」 だと思われます。また、Vaultのユーザーがkeypathを使ってVaultの条件から抜け出すオプションを望まないケースはなく、 scriptpath用に作成されたコントラクトにkeypathオプションを追加してもコストはかからないので、 keypathを有効にする方が厳密には優れていると主張する人もいます。

常にkeypathオプションを提供することに反対する論拠は、 一緒に行動する署名者が自分自身を信頼していない場合もあるということです。 代わりに他の人を、つまりBitcoinのコンセンサスルールを適用する経済的なフルノードのオペレーターを信頼し、 署名者が自身で適用したくない署名者の支払い能力に対する制限を適用します。

反論として、少なくとも純粋に理論的には、 通常の署名者とそのような経済的フルノードのオペレーターとでkeypathを作成し、 同じセキュリティを得ることができます。より現実的には、もしそれらが利用可能であれば、 あなたが望むポリシーを適用するkeypathマルチシグのセットに追加できるそれらのノードオペレーターのサブセット または代替セットがあるでしょう（そして、利用できなくてもscriptpathが利用できるので、何も失うことはありません）。

理屈はさておき、オプションとは思えない場合でも、 Taprootベースのコントラクトでkeypathを使用する機会があるかどうか、少し時間をかけて検討することをお勧めします。

リリースとリリース候補

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

  • ● Eclair 0.6.2は、上記のニュースに掲載されている脆弱性の修正および、 リリースノートに記載されている新しい機能やその他のバグ修正を含む新しいリリースです。

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

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

  • ● Bitcoin Core #20487では、実験的なシステムコール（syscall）のサンドボックスを有効にするための -sandbox設定オプションが追加されました。sandboxが有効な場合、 プロセス毎のホワイトリストに記載されている以外のシステムコールを実行すると、 カーネルがBitcoin Coreを終了させます。このモードは現在x86_64でのみ利用可能で、 主に特定のスレッドで使われているシステムコールをテストするためのものです。

  • ● Bitcoin Core #17211では、ウォレットのfundrawtransactionとwalletcreatefundedpsbt、 sendRPCメソッドを更新し、トランザクションで使用されるアウトプットのすべてがウォレットで所有されていないトランザクションも許可します。

    これまでは、ウォレットが所有していないアウトプットの使用する際に必要な手数料を見積もることができませんでした。 これはインプットでそのアウトプットを使用するために必要なサイズが分からなかったためです。 このPRでは、これらのRPCメソッドを更新し、solving_data引数を受け付けるようにしました。 トランザクションで使用されるアウトプットの公開鍵、シリアライズされたscriptPubKey、 もしくはdescriptorを提供することで、 ウォレットはそれらのアウトプットを使用するのに必要なインプットのサイズ（したがって、 アウトプットを使用するのに必要な手数料）を見積もることができます。

  • ● Bitcoin Core #22340 ブロックがマイニングされると、P2Pネットワークへブロードキャストされ、 最終的にネットワークのすべてのノードにリレーされます。従来、ブロックをリレーする方法には、 レガシーリレーとBIP152スタイルのCompact Block Relayの2種類がありました。

    ブロックオンリーのノードは、帯域幅の使用量を減らすためトランザクションリレーには参加しないので、 mempoolを持っていません。したがって、このようなノードでは常に完全なブロックをダウンロードする必要があるため、 Compact Blockはメリットがありません。しかし、高帯域幅モードでも低帯域幅モードでも、 cmpctblockメッセージはリレーされます。cmpctblockメッセージは、 headersやinvの通知に比べて平均的なケースで数倍の大きさになるため、 ブロックオンリーノードにとっては帯域幅のオーバーヘッドになります。

    ニュースレター #165に掲載したように、 このPRは、高帯域幅のブロックリレー接続を開始するのを防ぎ、sendcmpct(1)の送信を無効にすることで、 ブロックオンリーノードがレガシーリレーを使って新しいブロックをダウンロードするようにします。 さらに、ブロックオンリーノードは、getdata(CMPCT)を使ってCompact Blockを要求しなくなりました。

  • ● Bitcoin Core #23123では、-rescan起動オプションを削除しました。 ユーザーは代わりにrescanRPCを使用できます。

  • ● Eclair #1980は、Anchor Outputが使用されている場合、 ローカルのフルノードの動的な最小リレー手数料以上の手数料率で作成されたコミットメントトランザクションを受け入れます。

  • ● LND #5363では、LND内でPSBTのファイナライズのステップをスキップすることができ、 他のソフトウェアを使ってPSBTをファイナライズしブロードキャストできるようになりました。 これによりトランザクションのtxidが誤って変更された場合に資金が失われる可能性がありますが、 代替のワークフローが可能になります。

  • ● LND #5642では、経路探索操作を高速化するため、チャネルグラフのインメモリキャッシュを保持するようになりました。 これまでは、経路探索に高価なデータベースへの問い合わせが必要で、 PRの作者による計測では10倍以上遅かったようです。

    低メモリのシステム上でLNDを実行しているユーザーは、 routing.strictgraphpruning=trueフラグを使ってゾンビチャネルを積極的に削除することで、 この新しいキャッシュのメモリフットプリントを削減できます。

  • ● LND #5770では、上記のニュースセクションに掲載されているLNのCVEの緩和策を実装できるようにするため、 経済合理性のないアウトプットに関する詳細情報をLNDのサブシステムに提供するようになりました。