今週のニュースレターでは、Bitcoin Scriptを利用した衝突耐性ハッシュ関数と、 ライトニングネットワークのトラフィック分析に関する継続議論について掲載しています。 また、新しいリリースとリリース候補の発表や、人気のBitcoin基盤ソフトウェアの注目すべき更新など、 恒例のセクションも含まれています。

ニュース

  • ● Bitcoinスクリプト用の衝突耐性ハッシュ関数: Robin Linusは、 Bitcoin Scriptを使用した新しい衝突耐性ハッシュ関数であるBinohashについてDelving Bitcoinに投稿しました。 共有された論文でLinusは、Binohashは新たなコンセンサスの変更を必要とせずに 限定的なトランザクションイントロスペクションを可能にすると述べています。これにより、 BitVMブリッジのようなプロトコルは、信頼できるオラクルに依存することなく、 コベナンツのような機能を備えたトラストレスなイントロスペクションを実現できます。

    提案されたハッシュ関数は、２段階のプロセスを経てトランザクションダイジェストを間接的に生成します:

    • トランザクションフィールドの固定: トランザクションフィールドは、 支払人が複数の署名パズルを解くことを要求することで固定されます。 各パズルは、W1 bitの作業を必要とするため、不正な改変を計算コスト的に高価にします。

    • ハッシュの導出: ハッシュは、レガシーなOP_CHECKMULTISIGにおけるFindAndDeleteの挙動を利用して計算されます。 n個の署名でナンスプールが初期化されます。支払人は、t個の署名からなるサブセットを生成し、 FindAndDeleteを使ってプールから除去した後、残りの署名のsighashを計算します。 このプロセスは、sighashが要件に合致するパズル署名を生成するまで繰り返されます。 結果として得られるダイジェスト、すなわちBinohashは、勝利したサブセットのt個のインデックスで構成されます。

    この出力ダイジェストは、Bitcoinアプリケーションに関連する3つの特性を備えています。 Bitcoin Script内で完全に抽出および検証できること、約84 bitの衝突耐性があること、 そしてランポート署名が可能であるため、BitVMプログラム内でコミットできることです。 これらの特性により、開発者は既存のスクリプトプリミティブのみを使用して、 現在のオンチェーン上でトランザクションデータに関する推論を行うプロトコルを構築できます。

  • ● Gossip Observerトラフィック分析ツールに関する議論の続き: 11月に、 Jonathan Harvey-Buschelは、Gossip Observerを発表しました。 これはLNのゴシップトラフィックを収集し、メッセージフラッディングを セット・リコンシリエーションベースのプロトコルに置き換えることを評価するためのメトリクスを計算するツールです。

    それ以降、Rusty Russellらがスケッチの最適な送信方法についての議論に参加しました。 具体的には、メッセージのセットキーとしてブロック番号をサフィックスとして使用することで GETDATAの往復を省略し、受信者が関連するブロックコンテキストを既に推測できる場合に 不要なリクエスト/レスポンスの交換を回避するというものです。

    これに対し、Harvey-Buschelは、稼働中のGossip Observerのバージョンを更新し、 引き続きデータを収集しています。彼は１日あたりの平均メッセージ数の分析、 検出されたコミュニティのモデルおよび伝搬遅延を投稿しました。

リリースとリリース候補

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

  • ● BDK wallet 3.0.0-rc.1は、ウォレットアプリケーション構築用ライブラリの新しいメジャーバージョンのリリース候補です。 主な変更点としては、再起動後も保持されるUTXOロック、チェーンの更新時に返される構造化ウォレットイベント、 mainnetとtestnetを区別するためのAPI全体でのNetworkKindの採用などが挙げられます。 またこのリリースでは、Caravanウォレット形式（ニュースレター #77参照）の インポート/エクスポート機能と、バージョン1.0より前のSQLiteデータベース用の移行ユーティリティも追加されています。

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

最近の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 #26988は、-addrinfo CLIコマンド（ニュースレター #146参照）を更新し、 品質や新しさによってフィルタリングされたサブセットではなく、既知のアドレスの完全なセットを返すようになりました。 内部的には、getnodeaddresses RPC（ニュースレター #14参照）の代わりに getaddrmaninfo RPC（ニュースレター #275参照）が使用されます。 返されるカウントは、アウトバウンドピアの選択に使用されるフィルタリングされていないセットと一致するようになりました。

  • ● Bitcoin Core #34692は、4 GiB以上のRAMを搭載した64-bitシステムにおけるデフォルトのdbcacheを 450 MiBから1 GiBに増やし、それ以外の場合は450 MiBにフォールバックします。この変更は bitcoindのみに影響し、カーネルライブラリはデフォルトとして450 MiBを維持します。

  • ● LDK #4304は、HTLCの転送をリファクタリングし、 転送毎に複数の着信および送信HTLCをサポートすることで、 トランポリンルーティングの基盤を整備しました。 通常の転送とは異なり、トランポリンノードは両側でMPPエンドポイントとして機能できます。つまり、着信HTLCのパーツを蓄積し、 次のホップへの経路を見つけ、複数の送信HTLCに転送を分割します。 新しいHTLCSource::TrampolineForwardが、トランポリン転送のすべてのHTLCを追跡します。 請求と失敗は適切に処理され、チャネルモニターのリカバリは再起動時にトランポリン転送の状態を再構築するように拡張されました。

  • ● LDK #4416は、両方のピアが同時にスプライシングを開始しようとした場合に、 アクセプターが資金を拠出できるようにし、スプライシングにおける デュアル・ファンディングのサポートを実質的に追加しました。 両側が開始した場合、静止状態のタイブレークにより 一方がイニシエーターとして選択されます。これまではイニシエーターのみが資金を追加でき、 アクセプターは自身の資金を追加するために次のスプライシングを待つ必要がありました。 アクセプターはイニシエーターになる準備をしていたため、 その手数料は（共通のトランザクションフィールドをカバーする）イニシエーターレートからアクセプターレートに調整されます。 splice_channel APIは、最大手数料率をターゲットにするためのmax_feerateパラメーターも受け付けるようになりました。

  • ● LND #10089は、ニュースレター #377のメッセージタイプとRPCを基盤として、 オニオンメッセージの転送サポートを追加しました。 オニオンの内部ペイロードをデコードするOnionMessagePayloadワイヤータイプと、 復号と転送の判断を処理するピア毎のアクターを導入しています。この機能は --protocol.no-onion-messagesフラグで無効化できます。 これはLNDのBOLT12オファーサポートに向けたロードマップの一部です。

  • ● Libsecp256k1 #1777は、新しいsecp256k1_context_set_sha256_compression() APIを追加し、アプリケーションが実行時にカスタムSHA256圧縮関数を提供できるようにしました。 このAPIにより、起動時にCPU機能を検出するBitcoin Coreなどの環境が、 ライブラリを再コンパイルすることなく、libsecp256k1のハッシュ処理を ハードウェアアクセラレーションされたSHA256にルーティングできます。

  • ● BIPs #2047は、サイレントペイメントウォレット用の ディスクリプターを定義したBIP392を公開しました。 新しいsp()ディスクリプターは、BIP352で規定されたP2TRアウトプットである サイレントペイメントアウトプットのスキャンと使用方法をウォレットソフトウェアに指示します。 １つのKEY式を引数として取る形式は、単一のbech32m鍵を受け取ります。 監視専用のスキャン秘密鍵と使用公開鍵をエンコードするspscan、 またはスキャンと使用の両方の秘密鍵をエンコードするspspendです。 ２つの引数を取るsp(KEY,KEY)では、最初の式としてスキャン秘密鍵を受け取り、 ２つめの式として使用鍵を受け取り、使用鍵は公開鍵または秘密鍵のいずれかで、 BIP390によるMuSig2集約鍵もサポートしています。 最初のメーリングリストでの議論については、ニュースレター #387をご覧ください。

  • ● BOLTs #1316は、BOLT12オファーにおいて、 offer_amountが存在する場合はゼロより大きくなければならないことを明確にしました。 ライターはoffer_amountをゼロより大きい値に設定しなければならず、 リーダーは金額がゼロのオファーに応答してはなりません。無効なゼロ金額のオファーのテストベクターが追加されました。

  • ● BOLTs #1312は、無効なbech32パディングを持つBOLT12オファーの テストベクターを追加し、そのようなオファーはBIP173のルールに従って拒否されなければならないことを明確にしました。 この問題は、ライトニング実装間の差分ファジングを通じて発見され、CLNとLDKが無効なパディングを持つオファーを受け入れていた一方、 EclairとLightning-KMPは正しく拒否していたことが判明しました。 LDKの修正についてはニュースレター #390をご覧ください。

もっと知りたいですか？

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