今週のニュースレターでは、ライトニングネットワークのオフチェーンプロトコルをポスト量子セキュリティにアップグレードする提案を掲載しています。 また、Bitcoin Stack Exchangeから選ばれたQ&A、新しいリリースとリリース候補の発表、 人気のあるBitcoin基盤ソフトウェアへの注目すべき更新など、恒例のセクションも含まれています。

ニュース

  • ● ポスト量子ライトニングネットワークの提案: Ahmet Kurtは、ライトニングネットワークのオフチェーン部分を量子耐性を持つようにアップグレードする PQLNと呼ばれる新しい提案について、Delving Bitcoinに投稿しました。 この提案は、ニュースレター #408で取り上げたレイヤーごとの分析に基づいています。 著者と共同研究者はこのトピックに関する論文も公開しており、 rust-lightningをベースにした動作する実装もテスト用に提供されています。

    Kurtは、ライトニングネットワークの各レイヤーがポスト量子（PQ）セキュリティを達成するために どのように変更されたかを説明しました。ただし、オンチェーン操作に関わるレイヤーについてはコンセンサス変更が必要になるため、 変更は行われていないことを強調しました。主な変更点は以下の通りです。

    • ● ゴシップ（BOLT7）: PQ鍵はゴシップ自体を通じて直接配布されます。node_announcementメッセージには、 ノードのML-DSAおよびML-KEM公開鍵とML-DSA署名が含まれます。channel_updateメッセージには署名のみが含まれます。 鍵は固定されるため、ノードは鍵を置き換えようとするアナウンスを拒否できます。著者は、 channel_announcementメッセージは変更されていないと述べています。これは、 メッセージに必要な4つの署名のうち2つはオンチェーンのファンディング鍵で作成されるため、メッセージが部分的に偽造可能になってしまうからです。
    • ● トランスポート（BOLT8）: Noiseハンドシェイクは、2つのML-KEMカプセル化を使用するハイブリッド方式になります。 1つめは固定された静的鍵に対して行われ、もう1つは前方秘匿性を提供するために新しい一時鍵に対して行われます。 PQ攻撃者が関連するメッセージを容易に偽造できる可能性があるため、インバンドでのネゴシエーションは行われません。
    • ● インボイス（BOLT11）: インボイス内のタグ付きフィールドは最大639 byteしか保持できないため、 2420 byteのサイズを持つML-DSA-44署名は4つの異なるフィールドに分割する必要があります。
    • ● オファー（BOLT12）: オファーは独自のアンカーを持つため、 ノードはオファーごとに新しいML-DSA鍵をコミットします。支払人は、HTLCを送信する前に、 その鍵に対してインボイスを検証します。
    • ● オニオン（BOLT4）: ML-KEMの暗号文はそのサイズによりオニオン内に入れることができないので、 オニオンはフォーマットを維持しつつ、Sphinxのシークレットがハイブリッドになります。 暗号文はupdate_add_htlcメッセージ内の20スロットのリストとして、オニオンとともに送信されます。 ノードが経路の長さを推測できないようにするため、未使用の各スロットはダミーの暗号文で埋められます。

    Kurtによれば、この移行の真のコストは帯域幅です。ノードは、通常のLNノードの10倍のデータをダウンロードし、 9倍のデータを保存する必要があります。一方、計算量は問題になりません。実際、 最も高価な操作であるML-DSA署名は0.33 msしかかかりません。著者はregtest上でクラシカルなノードとの相互運用性をテストしました。 結果は良好で、PQLNノードは支払い経路上にクラシカルなノードがある場合は従来のプロトコルにフォールバックし、 require-PQフラグが設定されている場合はHTLCを送信する前に失敗しました。

    最後に著者は、いくつかの未解決の問題を提示しました。それらは、 暗号解読可能な量子コンピュータが登場する前に接続を確立していたノード間でのみ有効なピンニングの問題、 rust-lightningの1,024 byteのMAX_EXCESS_BYTES_FOR_RELAY制限により非PQノードがPQゴシップを中継できないこと、 そして機能ビットとTLVタイプの割り当てが未定であることなどです。

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

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

リリースとリリース候補

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

  • ● Bitcoin Core 32.0rc2は、主要なフルノード実装の次期メジャーバージョンのリリース候補です。 テストガイドが利用可能です。

  • ● Core Lightning 26.06.8は、この人気のあるLNノード実装のセキュリティリリースです。 責任ある形で報告された脆弱性に対するバグ修正が含まれています。ソースコードはすぐに利用可能です。 ただし、攻撃者が脆弱性を容易に特定できるようになる前にユーザーがアップグレードする時間を確保するため、 一部のテストは一時的に非公開となっています。開発ビルドを実行していたノードは、データベーススキーマが新しいため、 このリリースにダウングレードすることはできません。プロジェクトはアップグレードを強く推奨しています。

  • ● LDK v0.3-rc2は、LN対応のウォレットやアプリケーションを構築するための このライブラリの次期メジャーバージョンの2つめのリリース候補です。 保留中のスプライシングに対するRBFによる手数料引き上げと、 同じスプライシング内での資金の追加と削除のサポートが追加されました。また、 デフォルトでアンカーチャネルをネゴシエートし、 アプリケーションが受信チャネルを明示的に受け入れることを要求するようになりました。アップグレードすると、 以前に発行された支払いメタデータを含むBOLT11インボイスは無効になります。 開発者はテストの前にAPIおよび後方互換性の変更点を確認してください。

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

最近の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 #34566は、マルチsignetデータディレクトリのサポートを追加し（ニュースレター #412参照）、 カスタムsignet間でチェーンデータを競合させることなくベースのデータディレクトリを共有できるようにします。 各カスタムsignetは、signetチャレンジから導出された4 byteのネットワーク識別子を接尾辞とする signet_XXXXXXXXサブディレクトリを使用します。アップグレード後の再同期を避けるため、 既存のカスタムsignetユーザーは、ディレクトリを新しい形式に手動でリネームする必要があります。

  • ● BIPs #1951は、ディスクリプターやBIP388ウォレットポリシーのバックアップなど、 シード以外のウォレットデータ向けのコンパクトな暗号化方式の仕様であるBIP138を追加します（ニュースレター #351参照）。 暗号鍵は、ディスクリプター内の対象となる拡張公開鍵（xpub）のルート公開鍵から導出され、バックアップには、 それらの鍵のいずれかを保持する者が復号できるようにするリカバリデータが格納されます。共同署名者は、 他の共同署名者の鍵を必要とせずに、自身のシードからマルチシグディスクリプターを復元できます。 復号には公開鍵の情報のみを使用するため、ペイロードに秘密鍵を含めることはできません。 機密性は、xpubが決して開示されないことに依存します。LedgerやTrezorのデスクトップアプリのように、 アカウントのxpubをサーバーに送信するシングル署名ウォレットでは、 そのサーバーが同じxpubを再利用したマルチシグのすべてのバックアップを復号できてしまうため、 BIPはxpubが共有されていないBIP48やBIP87などのアカウントからマルチシグを構築することを推奨しています。

  • ● BIPs #2224は、単一の決定論的ECDSA署名アルゴリズムを規定するBIP461を追加します。 これにより、特定の秘密鍵とメッセージからは常に同じ署名が生成されることが保証されます。 署名者はRFC 6979でnonceを導出し、r値の先頭バイトがゼロにならないように カウンターを使ってリトライするlow-rグラインディングを適用し、 さらにsを小さな値に正規化します。出力が決定論的であるため、鍵の保持者は同じ鍵を2つの独立した署名者に読み込ませて、 同じメッセージに署名して結果を比較できます。何らかの違いがあれば、 少なくとも一方の署名者が仕様に従っていないことが明らかになり、 これはDark Skippy攻撃（ニュースレター #315参照）のように nonceの選択を通じて鍵の情報を漏洩させようとする試みを示唆している可能性があります。

  • ● Core Lightning #9507は、欠落していた手数料率の境界値チェックを追加し、 非常に大きな手数料見積もりがほぼゼロのレートに変わったり、 ノードが繰り返しクラッシュしたりする原因となっていたオーバーフローを修正します。これまでは、 ピアが提案するスプライシングや、 デュアルファンディングによるチャネル開設時のRBFの試行には手数料率の上限がなく、 デュアルファンディングの開設自体には下限と上限の両方のチェックがありませんでした。そのため、 次のRBF手数料率の計算でオーバーフローするほど大きな値や「0」が手数料率として保存されていると、 listpeerchannelsの実行時にアサーションエラーが発生していました。プラグインは起動時にこれを呼び出すため、 ノードは再起動のたびにクラッシュしていました。このPRは、--ignore-fee-limitsが有効な場合でも、 ピアの提案とバックエンドの手数料見積もりに対して4,000 sat/vBの上限を追加します。 また、CLNが行うチャネル開設、スプライシング、コミットメント更新、RBFに対して提案する手数料率を400 sat/vBに制限し、 アップグレード時に範囲外の保存済み手数料率を修正する処理も追加されています。

  • ● Core Lightning #9508は、いくつかのスプライシングとチャネル開設の問題を修正します。 これまでは、CLNがピアのsplice_lockedを受信する前に、 保留中のスプライシングに対するコミットメントトランザクションがピアによってブロードキャストされた場合、 それを見逃す可能性がありました。今回の修正により、CLNはすべての保留中スプライシングのファンディングアウトプットを監視し、 その使用を認識するようになります。また、CLNが署名を送信した後にピアがスプライシングに対してtx_abortを送信した場合、 CLNはチャネルを適切に強制閉鎖するようになりました。これまでは、このチェックは既に署名済みのスプライシングを認識できず、 署名が送信されたことを示すフラグが再起動をまたいで保持されていませんでした。このため、 CLNは強制閉鎖せずにtx_abortを受け入れていました。このPRはまた、 シングルファンディングのものを含め、既に3つのチャネル開設のネゴシエーションが進行中のピアからの 新しいデュアルファンディングのチャネル開設を拒否します。この制限を超えたピア、 またはチャネルを10分以上静止状態のままにしているピアとの接続は切断されます。

  • ● Core Lightning #9509は、オンチェーンでのチャネル解決に関するいくつかの問題を修正します。 これまでは、すべてのアウトプットが既知のシャットダウンスクリプトに支払われている場合、 CLNは強制閉鎖を協調閉鎖として扱ってしまう可能性がありました。 チャネル開設時に事前シャットダウンスクリプトにコミットしていなかったピアは、 古い失効済みコミットメントのアウトプットスクリプトを自身のシャットダウンスクリプトとして指定したshutdownメッセージを送信し、 協調閉鎖を中断させた上で、ペナルティを受けることなくそのコミットメントトランザクションをブロードキャストできました。 今回の修正により、CLNはアウトプットを確認する前に、ロックタイムとシーケンスのエンコーディングによってコミットメントトランザクションを識別します。 このPRはまた、承認済みのコミットメントトランザクションの監視対象である子孫トランザクションが再編成により無効化された場合、 ノードが再起動するまでチャネルを未監視のままにするのではなく、onchaindを再起動するようにします。 CLNは現在、送信HTLCの失敗が保留中であっても、オンチェーンでプリイメージが判明した場合には対応する未解決の受信HTLCを履行します。 追加の修正により、再編成された閉鎖アウトプットや、金額指定のないインボイスのフォールバックアドレスへのオンチェーン支払いに関連するクラッシュを防止する修正も行われています。

  • ● Core Lightning #9510と#9511は、入力のパースとログ記録を強化します。 前者は、非常に長いDNSホスト名をアナウンスしたノードにプロキシ経由で接続する際に connectdをクラッシュさせる可能性のあったバッファオーバーフローを修正します。 CLNは起動時に、自身の設定内の有効なホスト名ではないdns:アドレスを拒否し、 受信したノードアナウンスメント内の無効なDNSアドレスを無視します。また、JSONのネストを256レベルに、 RESTリクエストボディを2 MiBに制限し、不正な形式のメッセージによってCLNをクラッシュさせることができるBOLT12のTLVのパースバグを修正します。 後者のPRは、認証されていないRESTリクエストが非常に大きなパラメータでノードをクラッシュさせることを可能にしていたスタックオーバーフローを修正します。 また、素のRPCおよびプラグインのトラフィックにはrune（制限されたRPCアクセスを許可する認証トークン）や その他の秘密情報が含まれる可能性があるため、getlogからI/Oログを削除します。

  • ● Core Lightning #9513は、xpayがBOLT12オファーのインボイスを取得する際の金額検証を修正します。 これまでは、取得したインボイスの金額を承認済みの金額と照合せずに使用していたため、 受取人がより大きな支払いを要求することが可能でした。現在、インボイスは要求された金額と一致するか、 金額が指定されていない場合はオファーの金額を超えてはなりません。このPRはまた、任意のノードが送信できる、 ホップを持たない応答パスを含むオニオンメッセージによってノードが停止してしまう問題も防止します。 CLNは現在、そのようなパスを存在しないものとして扱い、その他のパース不能な応答パスについてはoffersプラグインを終了させるのではなくログに記録します。

  • ● LND #11198は、AMP支払いのプリイメージ再構築の失敗によってインボイス全体がキャンセルされてしまうバグを修正します。 再利用可能なAMPインボイスは、それぞれが複数のHTLCで構成される複数の独立した支払いセットを受け入れることができます。 これまでは、再構築の失敗が特定のセットにのみ影響するにもかかわらず、無効なセットによってインボイス全体がキャンセルされ、 受け入れ済みの他のセットにも支障をきたす可能性がありました。現在、LNDは到着したHTLCを失敗させ、 失敗したセットに属する以前に受け入れたHTLCをキャンセルします。インボイスは支払い可能なままで、 他の受け入れ済みセットは引き続き完了して決済できます。

  • ● LND #11146は、オファー、インボイスリクエスト、インボイス向けの検証付き文字列エンコーダーとデコーダーを追加することで、 BOLT12オファーの実装を継続します。これらはパースと、適用されるネットワーク、機能、有効期限、 署名のチェックを組み合わせたもので、ニュースレター #422で説明した署名サポートの上に構築されています。 新しいValidateInvoiceForPayment関数は、元となるリクエストと、支払人が署名すると想定していたノードに対してインボイスを検証します。 有効な署名だけでは不十分です。そうでなければ、ブラインドパス上のノードが自身の鍵で署名したインボイスを返すことができてしまいます。

  • ● LND #11132は、フラッドポリシーによって許可されたすべての有効なpingに応答することで、 BOLT1への準拠を回復します。これまでは、個別のpongリミッターが必要な応答を暗黙的に抑制する可能性がありました（ニュースレター #421参照）。 LNDは現在、ピアごとに200トークンを保持する単一のバケットを使用し、 トークンは毎秒10トークンの速度で補充されます。要求される応答が大きいほど多くのトークンを消費し、 最大サイズの応答には10トークンかかるため、以前の帯域幅制限が維持されます。予算を使い果たしたピアは切断されます。

もっと知りたいですか？

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