今週のニュースレターでは、Hornetノードによるコンセンサスルールの宣言的実行可能な仕様に関する取り組みと、 ライトニングネットワークにおけるオニオンメッセージのジャミングに関する議論を掲載しています。 また、Bitcoin Stack Exchangeから厳選された質問とその回答や、 新しいリリースおよびリリース候補の発表、人気のBitcoin基盤ソフトウェアの注目すべき更新など、 恒例のセクションも含まれています。

ニュース

  • ● HornetノードによるBitcoinコンセンサスルールの宣言的実行可能な仕様: Toby Sharpは、HornetノードプロジェクトのアップデートをDelving Bitcoinと Bitcoin-Devメーリングリストに投稿しました。 Sharpは以前、初期ブロックダウンロードの時間を167分から15分に短縮する 新しいノード実装Hornetについて説明していました。今回のアップデートでは、 34個のセマンティック不変条件をシンプルな代数を使って構成した、 非スクリプトブロック検証ルールの宣言的な仕様を完成させたことを報告しています。

    Sharpはまた、スクリプト検証への仕様の拡張を含む今後の作業について概説し、 Eric Voskuilからのフィードバックを受けて、libbitcoinなどの他の実装との比較の可能性についても検討しています。

  • ● ライトニングネットワークにおけるOnionメッセージのジャミング: Erick Cestariは、 ライトニングネットワークに影響を与えるOnionメッセージのジャミング問題について Delving Bitcoinに投稿しました。BOLT4は、Onionメッセージが信頼性のないものであることを認めており、 レート制限技術を適用することを推奨しています。Cestariによれば、 これらの技術こそがメッセージジャミングを可能にするとされています。攻撃者は悪意あるノードを立ち上げ、 スパムメッセージでネットワークを溢れさせることでピアのレート制限を発動させ、 正当なメッセージをドロップさせることができます。さらに、BOLT4は最大メッセージ長を強制していないため、 攻撃者は単一のメッセージのリーチを最大化することが可能です。

    Cestariは、オニオンメッセージのジャミングに対するいくつかの緩和策をレビューし、 より適切であると判断した技術について包括的な説明を提供しています:

    • ● 前払い手数料: この手法は、Carla Kirk-Cohenが BOLTs #1052で最初に提案したものですが、容易に拡張ができます。ノードはメッセージ毎の定額手数料を通知し、 それをオニオンペイロードに含めて各ホップで差し引きます。手数料が支払われない場合、メッセージはノードによってドロップされます。 この手法は、チャネルピアへのメッセージ転送しかできないことや、P2Pオーバーヘッドの増加といったいくつかの制限があります。

    • ● ホップ制限とチャネル残高に基づくProof of Stake: この手法は、 アルバータ大学のBashiriとKhabbazianによって提案されたもので、2つの異なるコンポーネントを持ちます:
      • ホップ数の制限: メッセージを送れる最大ホップ数（例：3ホップまで）にハードキャップを設定するか、 送信者にProof of Workのパズルを解かせ、その難易度をホップ数に応じて指数関数的に増加させます。
      • Proof of Stake転送ルール: 各ノードは、ピアの集約チャネル残高に応じてピア毎のレート制限を設定し、 十分な資金を持つノードにより多くの転送能力を与えます。

      このアプローチのトレードオフは、大規模ノードが有利になることによる中央集権化への圧力と、 3ホップのハードキャップが匿名セットの減少につながることです。

    • ● 帯域幅計測型支払い: Olaoluwa Osuntokunによって提案されたこの手法は、 前払い手数料と同様のスコープを持ちますが、セッションごとの状態を追加し、AMP支払いを通じて決済します。 送信者はまずAMP支払いを送信し、各中間ステップで手数料を落としながらセッションIDを届けます。 その後、送信者はオニオンメッセージにそのIDを含めます。このアプローチの既知の制限は、 チャネルピアへのメッセージ転送しかできないことと、同じセッションに属するすべてのメッセージをリンクできる可能性です。

    • ● 逆伝播ベースのレート制限: Bastien Teinturierによって提案されたこのアプローチは、 統計的にスパムをその発信源までたどることができるバックプレッシャー機能を使用します。ピアごとのレート制限に達した場合、 ノードは送信者にドロップメッセージを送り返し、送信者はそのメッセージをレート制限を半分にしてメッセージを転送した最後のピアにリレーします。 正しい送信者は統計的に識別されますが、誤ったピアがペナルティを受ける可能性があります。 さらに攻撃者はドロップメッセージを偽造し、正直なノードのレート制限を下げることもできます。

    最後にCestariは、最近Torで起きたような長期的なDDoS攻撃がネットワークに及ぶ前に、 この問題を緩和するための猶予がまだ残っているとして、LN開発者に議論への参加を呼びかけています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • ● Bitcoin Core 31.0は、ネットワークの主要なフルノード実装の最新のメジャーリリースです。 リリースノートでは、クラスターmempool設計の実装や、 sendrawtransactionの新しい-privatebroadcastオプション（ニュースレター #388参照）、 エクリプス攻撃から保護するためにオプションでバイナリに埋め込まれたasmapデータ、 4096 MiB以上のRAMを搭載したシステムにおける-dbcacheのデフォルト値を1024 MiBに引き上げ、 その他多くの更新など、いくつかの重要な改善について説明しています。

  • ● Core Lightning 26.04は、この人気のLNノード実装のメジャーリリースです。 デフォルトでスプライシングを有効にし、 スプライスアウトの宛先として2つ目のチャネルを対象にするcross-spliceモードを含む 新しいspliceinおよびspliceoutコマンドを追加し、収入のサマリ用のbkpr-reportを再設計し、 askreneでの並行経路探索と複数のバグ修正を追加し、offer RPCと payment-fronting-node設定にfronting_nodesオプションを追加し、 レガシーオニオンフォーマットのサポートを削除します。詳細は、リリースノートをご覧ください。

  • ● LND 0.21.0-beta.rc1は、この人気のLNノードの次期メジャーバージョンの最初のリリース候補です。 SQLiteまたはPostgreSQLバックエンドに対して--db.use-native-sqlフラグを指定してノードを実行しているユーザーは、 このバージョンでは、--db.skip-native-sql-migrationによるオプトアウトにより、 ペイメントストアがkey-value形式からネイティブSQLに移行されることに注意してください。 リリースノートをご覧ください。

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

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

  • ● Bitcoin Core #33477は、assumeUTXOスナップショットに使用される 過去のUTXOセットダンプを構築するためのdumptxoutset RPCのrollbackモード（ニュースレター #72参照）を更新します。 ブロックを無効化してメインのchainstateをロールバックする代わりに、 Bitcoin Coreは一時的なUTXOデータベースを作成し、要求された高さまでロールバックして、 その一時データベースからスナップショットを書き出します。これにより、 追加の一時ディスク容量とダンプの遅延というコストと引き換えに、メインのchainstateを保持し、 ネットワーク活動を停止する必要性とロールバック時のフォーク関連の干渉リスクを排除します。 新しいin_memoryオプションは、一時UTXOデータベースをすべてRAM上に保持することで、 より高速なロールバックを可能にしますが、mainnetでは10GB以上の空きメモリが必要です。 深いロールバックを行う場合、数分かかる可能性があるため、RPCのタイムアウトをなしにする（ bitcoin-cli -rpcclienttimeout=0）のを忘れないようにしてください。

  • ● Bitcoin Core #35006は、bitcoin-cliに-rpcidオプションを追加し、 JSON-RPCリクエストのidとして、デフォルトのハードコードされた値の1の代わりに カスタム文字列を設定できるようにします。これにより、複数のクライアントが同時に呼び出しを行う際に、 リクエストとレスポンスを相関付けることができます。この識別子はサーバー側のRPCのデバッグログにも含まれます。

  • ● BIPs #1895は、ポスト量子移行と レガシー署名の利用終了に関する抽象的な提案であるBIP361を公開しました。 別途ポスト量子（PQ）署名スキームが標準化され展開されることを前提として、 ECDSA/Schnorr署名スキームからの段階的移行を概説しています。 現在のバージョンの提案は2つのフェーズに分かれています。フェーズAは、量子脆弱なアドレスの資金の送金を禁止し、 それによってPQアドレスタイプの採用を加速させます。フェーズBでは、量子脆弱なUTXOからの盗難を防ぐために、 ECDSA/Schnorr署名を使用する支払いの制限と量子安全なレスキュープロトコルが含まれています。

  • ● BIPs #2142は、サイレントペイメントのBIP提案であるBIP352を更新し、 インプットの鍵の合算値が、2つのインプットの段階で一旦ゼロになるものの、全インプットを合算するとゼロにはならない というエッジケースに対する送受信のテストベクトルを追加します。これによりすべてのインプットをまず合算するのではなく、 インクリメンタルな合算の途中で早期に拒否してしまう実装を検出できます。

  • ● LDK #4555は、転送ノードがブラインドされた支払い経路に対して max_cltv_expiryを適用する方法を修正します。このフィールドは、 期限切れのブラインドルートがブラインドセグメントを通じて転送されて受信者に近い場所で失敗するのではなく、 導入ホップで拒否されることを保証することを意図しています。これまでは、LDKはこの制約をホップの送信CLTV値と比較していましたが、 現在は意図どおり受信CLTVの有効期限をチェックするようになっています。

  • ● LND #10713は、受信するオニオンメッセージに対して ピアごとおよびグローバルなトークンバケットレート制限を追加し、オニオンハンドラーに到達する前に 入口で過剰なトラフィックをドロップします。これにより、LNDに最近追加されたオニオンメッセージの転送サポート（ ニュースレター #396参照）が、高速ピアからの大量の悪用に対して強化されます。 ピアごととグローバルの分割は、LNDの以前のゴシップ帯域幅制限（ニュースレター #370参照）を踏襲しています。

  • ● LND #10754は、選択された次のホップがメッセージを届けたピアと同じピアである場合、 オニオンメッセージの転送を停止し、同じ接続での即時バウンスを回避します。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。