今週のニュースレターでは、帰属障害がLNのプライバシーに影響を及ぼす可能性について掲載しています。 また、Bitcoin Stack Exchangeから厳選された質問とその回答や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの最近の更新など 恒例のセクションも含まれています。

ニュース

  • ● 帰属障害はLNのプライバシーを低下させる？ Carla Kirk-Cohenは、ネットワークが失敗の帰属、 特に各ホップで支払いを転送するのにかかった時間を支払人に伝える場合、 LNの支払人と受取人のプライバシーにどのような影響が及ぶ可能性があるかについての分析を Delving Bitcoinに投稿しました。 彼女は複数の論文を引用しながら、2種類の非匿名化攻撃について説明しています:

    • 1つ以上の転送ノードを運用する攻撃者が、タイミングデータを使って 支払い（HTLC）に使用されたホップ数を特定します。 このデータと公開ネットワークのトポロジーに関する知識を組み合わせることで、 受取人の可能性があるノードのセットを絞り込むことができます。

    • ● 攻撃者が、IPネットワークトラフィックフォワーダー（自律システム）を使ってトラフィックを受動的に監視し、 ノード間のIPネットワークのレイテンシー（つまりping時間）の知識と、 公開ライトニングネットワークのトポロジー（およびその他の特性）に関する知識を組み合わせることができます。

    次に彼女は、以下の解決策を挙げています:

    • 受取人にHTLCの受け入れを小さなランダム時間分遅らせることを推奨し、 受取人のノードを特定しようとするタイミング攻撃を防止する。

    • ● 支払人に失敗した支払い（またはMPPの一部）の再送を 小さなランダム時間分遅らせ、代替パスを使うことで、 支払人のノードを特定しようとするタイミング攻撃や失敗攻撃を防止する。

    • MPPによる支払いの分割数を増やし、支払額の推測を困難にする。

    • ● 以前の提案のように（ニュースレター #208参照）、 支払人が支払いをより遅く転送されることを選択できるようにする。 これは、LNDで既に実装されているHTLCバッチ処理と組み合わせることもできる（ ランダム時間の遅延の追加によりプライバシーを強化できる）。

    • 小さなランダム遅延を追加する転送ノードへのペナルティを回避するため、 原因となる失敗のタイムスタンプの精度を下げる。

    複数の参加者による議論では、懸念事項と提案された解決策をより詳細に評価し、 その他の可能性のある攻撃と軽減策についても検討されました。

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

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

リリースとリリース候補

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

  • ● Core Lightning 25.05rc1は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。

  • ● LDK 0.1.3および0.1.4は、LN対応アプリケーションを構築するための この人気のライブラリのリリースです。バージョン0.1.3はGithub上では今週のリリースとしてタグ付けされていますが、 リリース日は先月になっており、サービス拒否攻撃に対する修正が含まれています。 最新リリースであるバージョン0.1.4では「極めて稀なケースで発生する資金窃盗の脆弱性を修正」しています。 両リリースには、その他のバグ修正も含まれています。

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

最近の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 #31622は、署名ハッシュ（sighash）タイプが SIGHASH_DEFAULTまたはSIGHASH_ALLと異なる場合に、 PSBTにそのフィールドを追加します。 MuSig2のサポートでは、全員が同じsighashタイプで署名する必要があるため、 このフィールドはPSBTに必須です。さらに、descriptorprocesspsbt RPCコマンドは、 SignPSBTInput関数を使用するように更新され、 PSBTのsighashタイプがCLIで指定されたタイプと一致することを保証します（該当する場合）。

  • ● Eclair #3065は、BOLTs #1044で定義されている 帰属障害（ニュースレター#224参照）のサポートを追加します。 仕様がまだ確定していないためデフォルトでは無効になっていますが、 eclair.features.option_attributable_failure = optionalを設定することで有効にできます。 LDKとの相互互換性はテスト済みです。LDKの実装とこのプロトコルの動作に関する詳細については、 ニュースレター#349をご覧ください。

  • ● LDK #3796は、チャネル残高チェックを強化し、 資金提供者がコミットメントトランザクションの手数料、 2つの330 satsのアンカーアウトプット、 そしてチャネルリザーブを賄うのに十分な資金を確保できるようにします。 これまでは、資金提供者は、2つのアンカーを賄うためにチャネルリザーブを利用できました。

  • ● BIPs #1760は、SPVクライアントに対して悪用可能な マークルツリーの脆弱性を防ぐため、 （witnessデータを除いた）64-byteのトランザクションを禁止するコンセンサスソフトフォークルールを規定した BIP53をマージしました。このPRは、 コンセンサスクリーンアップソフトフォークに含まれるものと同様の修正を提案しています。

  • ● BIPs #1850は、Taproot（P2TR）の導出用にスクリプトタイプの値3を予約した BIP48の以前の更新（ニュースレター #353参照）を元に戻しました。 これは、TapscriptにOP_CHECKMULTISIGがないため、 BIP48が依存するBIP67で参照されているアウトプットスクリプトをP2TRで表現できないためです。 このPRはまたBIP48のステータスをFinalとしています。 これはBIP導入時の目的が、新しい動作を規定することではなく、 m/48' HDウォレット導出パスの業界における使用を定義することが目的であったことを反映しています。

  • ● BIPs #1793は、（アウトプットとインプット両方の）公開鍵が任意のデータにコミットしていることを確認できる OP_CHECKCONTRACTVERIFY（OP_CCV） opcodeを提案するBIP443をマージしました。 この提案されたコベナンツの詳細については、ニュースレター#348をご覧ください。