en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #335

Jan 3, 2025

今週のニュースレターでは、集中型のCoinjoinプロトコルを使用するソフトウェアにおける長年の非匿名化の脆弱性に関する情報のリンクと、スクリプトレスな閾値署名と互換性のある ChillDKG分散鍵生成プロトコルに関するBIPドラフトの更新について掲載しています。また、Bitcoinのコンセンサスルールの変更に関する議論の概要や、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● 集中型Coinjoinに対する非匿名化攻撃: Yuval Kogmanは、 WasabiとGingerウォレットの現在のバージョンおよび、Samourai、Sparrow、 Trezor Suiteソフトウェアウォレットの過去のバージョンで使用されるCoinjoinプロトコルのプライバシーを低下させるいくつかの脆弱性について、詳細をBitcoin-Devメーリングリストに投稿しました。 Kogmanは、WasabiとGingerで使用されるWabiSabiプロトコルの設計に携わりましたが（ニュースレター #102参照）、「リリース前に抗議し、離脱しました」。脆弱性が悪用されると、集中型のコーディネーターは、どのユーザーがどのアウトプットを受け取ったかを判断できるため、単純なWebサーバーではなく高度なプロトコルを使用する利点がなくなります。 Kogmanは、この脆弱性が複数のウォレット開発者に何年も前から知られていた証拠を示しています。同じソフトウェアの一部に影響する同様の脆弱性については、以前ニュースレター #333で言及されています。
● ChillDKGドラフトの更新: Tim RuffingとJonas Nickは、 BitcoinのFROSTスクリプトレス閾値署名と互換性のある分散鍵生成プロトコルを記述した ChillDKGの現在のBIPのドラフトのリンクをBitcoin-Devメーリングリストに投稿しました。最初の発表（ニュースレター #312参照）から、セキュリティの脆弱性を修正し、問題のある参加者を特定できる調査フェーズを追加し、バックアップとリカバリーをより容易にしました。また、Sivaram Dhakshinamoorthyと協力して、彼の提案するBitcoinと互換性のあるFROST署名（ニュースレター #315参照）との同期を保っています。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた新しい月次セクション

● CTV拡張opcode: 開発者のmoonsettlerは、すでに提案されているOP_CHECKTEMPLATEVERIFYと組み合わせて使用する2つの追加opcodeの提案を Bitcoin-DevメーリングリストとDelving Bitcoinの両方に投稿しました:
- OP_TEMPLATEHASH は、トランザクションの要素のリストを取得し、それをCTV互換のハッシュに変換します。これにより、スタック操作で、使用するインプット、インプットの数、ロックタイム、各アウトプットの金額、各アウトプットのスクリプト、アウトプットの数、使用するトランザクションのバージョンに関する詳細を指定できます。
- OP_INPUTAMOUNTS は、インプットの一部またはすべてのsatoshiの金額をスタックに配置し、 OP_TEMPLATEHASHのパラメーターとして使用できるようにします（たとえば、アウトプットに同じ金額を要求するなど）。
これらのopcodeを組み合わせると、BIP345のOP_VAULTで可能なものと同様の特性を持つ Vaultを作成できます。opcodeは、他のコントラクトプロトコルに加えて、よりオンチェーン効率の高い種類のアカウンタブルコンピューティングを実装するのに便利かもしれません。この記事の執筆時点では、Delving Bitcoinのスレッドで議論が進行中でした。
● 256 bitを超える難易度の調整: Andersは、ブロックヘッダーで使用可能な256 bitを超えるPoW（Proof of Work）難易度の調整に関する懸念を Bitcoin-Devメーリングリストに投稿しました。これには、ハッシュレートの計り知れない増加（現在のレートの約2¹⁷⁶倍の増加）が必要になりますが、それが実現した場合、Michael Cassanoは、フォークによってセカンダリハッシュターゲットが追加され、ブロックを有効にするためには、プライマリターゲットとセカンダリターゲットの両方を満たす必要があると指摘しています。これは、ブロック保留攻撃を軽減するための提案と似ています（ニュースレター #315参照）。 フォワードブロック （ニュースレター #16参照）などの提案を含むこの種のフォークは、既存のルールを強化するだけなので、技術的にはソフトフォークとなる可能性がありますが、アップグレードされていないフルノードや、潜在的にすべての軽量（SPV）クライアントが、実際には承認がゼロであるにもかかわらず、あるトランザクションに何百、何千もの承認があるかのにように騙されたり、実際に承認されたトランザクションと競合したりしやすくなるため、そのような分類を使用したくないと考える開発者もいます。
● クリーンアップソフトフォークのための一時的なソフトフォーク: Jeremy Rubinは、脆弱性を軽減または修正するために設計されたコンセンサスルールを一時的にのみ適用することについて Delving Bitcoinに投稿しました。このアイディアは、新機能を追加するソフトフォークのために以前提案されていましたが（ニュースレター #197参照）、新機能の支持者からも、提案に態度を決めかねているコミュニティメンバーからも支持を得られませんでした。 Rubinは、このアイディアは脆弱性を修正しようとするものの、ユーザーが誤ってビットコインを使用できなくなるリスク（没収リスクと呼ばれる）や将来の脆弱性を容易に修正する能力が制限されたりするリスクを伴うソフトフォークにより適していると示唆しています。 David Hardingは、一時的なソフトフォークのアイディアが以前支持を得なかったのは、数年ごとにコンセンサス変更の賛否を再度議論する必要があるということを、支持者も態度を決めかねているコミュニティメンバーも望んでいなかったからであり、この懸念は、変更が機能を追加するものであっても、脆弱性に対処するものであっても同じように適用されると主張しました。
● 量子コンピュータのアップグレードパス: Matt Coralloは、高速な量子コンピューターによる偽造リスクのためにECDSAおよびSchnorr 署名が無効になっている場合でも資金を使用できるように、 Tapscriptに量子耐性署名チェックopcodeを追加することについて Bitcoin-Devメーリングリストに投稿しました。。Luke Dashjrは、将来的に量子耐性のある署名チェックopcodeがどのように機能するかについて現在広く合意されている限り、ユーザーは後で利用可能になる可能性のあるオプションとしてコミットするだけでいいため、現時点でソフトフォークは不要であると指摘しました。Tadge Dryjaは、量子コンピューターがビットコインを盗む寸前であると思われる場合に、量子安全ではないECDSAやSchnorr署名の使用を一時的に制限する一時的なソフトフォークを提案しました。その後、誰かが量子コンピューターでのみ解決可能なオンチェーンパズルコントラクトを解決した場合（または基本的な暗号の脆弱性が発見された場合）、一時的なソフトフォークは自動的に永続的になります。そうでない場合、一時的なソフトフォークは更新されるか、失効します（ECDSAとSchnorrによって保護されたビットコインが再度使用可能になります）。
● コンセンサスクリーンアップのタイムワープ猶予期間: Sjors Provoostは、新しい難易度期間の最初のブロックが前の期間の最後のブロックより600秒以上前の時刻を持つことを禁止することで、タイムワープ攻撃を軽減するコンセンサスクリーンアップの提案について、 Delving Bitcoinに投稿しました。Provoostは、タイムスタンプの範囲を使用してnonceのスペースを拡張する（タイムローリング と呼ばれる）ソフトウェアを使用する正直なマイナーが、クロックの遅いノードがすぐに受け入れないかもしれないブロックを誤って生成し、同じ時刻に生成される可能性のあるタイムスタンプの変動が少ない競合ブロックに比べて、ブロックの伝播が遅くなることを懸念しています。競合ブロックがベストブロックチェーンに残れば、タイムローリングブロックのマイナーは収益を失うことになります。Provoostは代わりに、 7,200秒（約2時間）を超えて時間を逆行させることを禁止するなど、より緩やかな制限を提案しています。 Antoine Poinsotは、600秒という選択は既知の問題を回避し、将来の時間の歪みに対する最も強力な防御を提供するものだと主張しています。

リリースとリリース候補

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

● BDK wallet-1.0.0は、Bitcoinウォレットやその他のBitcoin対応アプリケーションを構築するためのこのライブラリの最初のメジャーリリースです。元のbdkRustクレートの名前が bdk_walletに変更され（APIは安定を保つよう設計）、下位層のモジュールは bdk_chain、bdk_electrum、bdk_esplora、bdk_bitcoind_rpcなどの独自のクレートに抽出されました。
● LND 0.18.4-betaは、この人気のLN実装のマイナーリリースで、「通常のバグ修正と安定性の向上に加えて、カスタムチャネルの構築に必要な機能を提供します」。
● Core Lightning v24.11.1は、実験的なxpayプラグインと古いpay RPC間の互換性を改善し、xpayユーザー向けに他のいくつかの改善を加えたマイナーリリースです。
● Bitcoin Core 28.1rc2は、主流のフルノード実装のメンテナンスバージョンのリリース候補です。
● LDK v0.1.0-beta1は、LN対応ウォレットとアプリケーションを構築するためのこのライブラリのリリース候補です。

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

最近の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 #31223は、ノードが「Torサービスターゲット」 P2Pポートを導出する方法（ニュースレター#118参照）を変更します。 -portの値が指定されている場合は、デフォルトの8334ではなく、ユーザーが指定した-port値に1を加えた値を使用します。これにより、複数のローカルノードがすべて8334にバインドされ、ポートの衝突によりクラッシュするという問題が修正されます。ただし、稀に2つのローカルノードに連続した-port値が割り当てられた場合、導出されたonionポートが衝突する可能性がありますが、これは完全に回避する必要があります。
● Eclair #2888は、BOLTs #1110で定義されているピアストレージプロトコルのサポートを実装します。これにより、ノードはそれを要求するピアの暗号化されたバックアップをデフォルトで最大65kBまで保存できます。この機能は、モバイルウォレットを提供するLSP（Lightning Service Provider）を対象としており、ノードオペレーターがデータを保存する期間を指定できる設定があります。これによりEclairは、 CLNに続いて（ニュースレター#238参照）ピアストレージをサポートする２つめの実装になります。
● LDK #3495は、ランダム化されたプローブから収集された実際のデータに基づいて確率密度関数 (PDF)と関連パラメーターを改善することで、 LNの経路探索における過去の成功確率スコアリングモデルを改良します。このPRは、過去のモデルと事前モデルを実際の動作に合わせて、デフォルトのペナルティを強化し、経路探索の信頼性を向上させます。
● LDK #3436は、lightning-liquidityクレートをrust-lightningリポジトリに移動します。このクレートは、（ここで定義されている）LSPをLDKベースのノードと統合するための型とプリミティブを提供します。
● LDK #3435は、ブラインドパス支払いコンテキストメッセージに認証フィールドを追加し、支払人がHMAC（Hash-based Message Authentication Codes）とnonceを含め、受信者が支払人を認証できるようにします。これにより、攻撃者が被害者ノードが発行したBOLT11インボイスから payment_secretを取得し、そのオファーに期待される金額と一致しない場合でも支払いを偽造できる問題が修正されます。また同じ手法を用いた非匿名化攻撃の防止にも役立ちます。
● LDK #3365は、アップグレード時にholder_commitment_point（次のコミットメントポイント）を、以前使用したPendingNext状態のままにするのではなく、 get_channel_reestablishで取得することでアップグレード時にすぐに使用可能としてマークされるようにします。この変更により、アップグレード中にチャネルが安定状態にあり、次のコミットメントポイントが使用可能であることを求めるcommitment_signedメッセージを受信した際に、強制閉鎖されるのが防止されます。
● LDK #3340は、Pinning可能なアウトプットを持つオンチェーンの請求トランザクションのバッチ処理を導入し、強制閉鎖シナリオでのブロックスペースの使用と手数料を削減します。これまでは、アウトプットはノードによって排他的に請求可能で、Pinningが不可能な場合のみバッチ処理されていました。現在は、取引相手が使用できる高さから12ブロック以内のアウトプットは、 HTLCタイムアウトのロックタイムと組み合わせることができる限り、 Pinning可能として扱われ、それに応じてバッチ処理されます。
● BDK #1670では、新しいO(n)正規化アルゴリズムが導入され、正規のトランザクションを識別し、ウォレットのベストローカルチェーンの視点で承認される可能性が低い（非正規）未承認の競合を削除します。この大幅に効率的なアプローチは、特定のユースケースで DoSリスクとなる可能性のあるO(n²)ソリューションを提供していた古いget_chain_positionメソッドを置き換えて削除します。
● BIPs #1689は、BIP374をマージし、Bitcoinで使用される楕円曲線（secp256k1）の離散対数の等価性の証明（DLEQ）を生成および検証する標準的な方法を定義します。このBIPは、複数の個別の署名者を使用して作成されたサイレントペイメントのサポートを目的としています。 DLEQを使用すると、すべての署名者は秘密鍵を公開することなく、共同署名者に対して署名が有効であり、資金を失うリスクがないことを証明できます。
● BIPs #1697は、細かい文法変更を行うことで、テンプレート化されたアウトプットスクリプトディスクリプターのセットに MuSigサポートを追加するため、BIP388を更新します。
● BLIPs #52は、BOLT8ピアツーピアメッセージ上のJSON-RPCフォーマットを使用して、 LSPノードとそのクライアント間の通信で使用されるプロトコルを定義するため、BLIP50を追加します。これは、LSPの仕様リポジトリの上流のBLIPセットの一部であり、複数のLSPおよびクライアント実装で実際に稼働しているため、安定しているとみなされています。
● BLIPs #54は、LNチャネルを持っていないクライアントが支払いの受け取りを始められるようにする JITチャネルを定義するためにBLIP52を追加します。 LSPが支払いを受け取ると、それに応じてクライアントへのチャネルが開かれ、チャネルの開設コストが最初に受け取った支払いから差し引かれます。これもLSPの仕様リポジトリの上流のBLIPセットの一部です。