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

Bitcoin Optech Newsletter #131

Jan 13, 2021

今週のニュースレターでは、新しく提案されたBitconのP2Pプロトコルメッセージ、変更されたbech32アドレスフォーマットのBIPおよび提案されたデュアルファンドLNチャネルにおけるUTXOプロービングを防止するアイディアについて説明します。また、Bitcoin Core PR Review Clubのミーティングや、リリースおよびリリース候補のリスト、人気のあるBitcoinのインフラストラクチャソフトウェアの注目すべき変更の解説を含む定期的なセクションも含まれています。

ニュース

● disabletxメッセージの提案 2012年にBIP37が公開され、軽量クライアントは、クライアントがbloom filterをロードするまで、未承認トランザクションをクライアントにリレーしないようピアに要求できるようになりました。 Bitcoin Coreはその後このメカニズムを帯域幅を削減する-blocksonlyモードに再利用しました。このモードでは、ノードは自身のピアに未承認のトランザクションを送信しないよう要求します。昨年、デフォルト設定のBitcoin Coreは、帯域幅を大幅に増加させたり、プライバシーを低下させたりすることなく、エクリプス攻撃に対する耐性を向上させる効率的な方法として、 2つのblock-relay-only接続を開くようになりました（Newsletter #63参照）。しかし、トランザクションリレーを抑制するために使用されているBIP37のメカニズムは、開始ノードがいつでも完全なトランザクションリレーを要求することが可能です。トランザクションリレーはメモリや帯域幅などのリソースを消費するため、ノードはBIP37ベースの低帯域幅のblocks-relay-only接続が突然フルトランザクションリレー接続になる可能性を想定して接続制限を設定する必要があります。

今週、Suhas Daftuarは、接続のネゴシエーション中に送信される可能性のある新しいdisabletxメッセージの提案を Bitcoin-Devメーリングリストに投稿しました。このメッセージを理解し、BIPの推奨事項をすべて実装したピアは、 disabletxを要求するノードにトランザクションの通知を送信せず、ノードにトランザクションを要求しません。 disabletxのネゴシエーションは接続が有効な期間持続するため、現在の最大接続数125を超える追加の接続を受け入れるなど、無効化されたリレー接続に異なる制限を使用することができます。
● Bech32m Pieter Wuilleは、Bitcoin-Devメーリングリストにbech32アドレスエンコーディングの修正バージョンのBIPドラフトを投稿しました。修正バージョンではbech32mアドレス内に誤って文字が追加されたり削除されたりした場合に、それが検出される可能性が高くなります。この提案に問題がない場合、bech32mアドレスがtaprootアドレスや将来の新しいスクリプトのアップグレードに使用されることが期待されます。 bech32mアドレスへの支払いをサポートするウォレットやサービスの実装は、自動的に将来のすべての改善の支払いをサポートします（詳細についてはNewsletter #45を参照）。
● LNデュアルファンディングにおけるUTXOプルービング対策: LNの長期的な目標は、デュアルファンディングで、チャネルを開始したノードとそのリクエストを受信したピアの両方からの資金でチャネルを開くことができます。これによりチャネルが完全にオープンした瞬間から、どちらの方向にも支払いができるようになります。開設者がデュアルファンディングトランザクションに署名する前に、相手側がトランザクションに追加したいすべてのUTXOのID（OutPoint）を提供する必要があります。このため、悪用者は多数の異なるユーザーとデュアル・ファンドチャネルを開始し、彼らのUTXOについて学習した上で、ファンディングトランザクションへの署名を拒否することができ、悪用者のコスト負担なくこれらのユーザーのプライバシーが損なわれるというリスクが生じます。

今週、Lloyd Fournierは、この問題に対処するための２つの以前の提案の評価をLightning-Devメーリングリストに投稿しました。１つは離散対数の等価性の証明(PoDLEs、Newsletter #83参照)を使用し、もう１つはSIGHASH_SINGLE|SIGHASH_ANYONECANPAYを使って半署名されたデュアルファンディングトランザクションを使用します。 Fournierは以前の半署名された提案を拡張し、それと同等の効果のあるよりシンプルな彼独自の提案を提供しました。新しい提案では、開設者は自分のUTXOを自身に戻すトランザクション（グッド・フェイス）を作成し、署名します（ブロードキャストはしません）。そしてこのトランザクションを誠実さの証として相手に渡します。開設者が後になって実際のファンディングトランザクションに署名しなかった場合、相手はグッド・フェイストランザクションをブロードキャストして、開設者にオンチェーン手数料を負担させることができます。 Fournierは、異なるアプローチ間のトレードオフをまとめて投稿を締めくくっています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、重要な質問と回答のいくつかに焦点を当てます。以下の質問をクリックしてミーティングの回答の要約を確認してください。

ノードの排除ロジックの単体テストの追加は、仮名の貢献者practicalswiftによる、ノードのインバウンド接続スロットが一杯になった時のBitcoin Coreのピア排除ロジックのテストカバレッジを向上させるためのPR (#20477) です。このロジックを使用して、攻撃者がトリガーするネットワーク分断にノードをさらさないよう注意する必要があります。

議論のほとんどはBitcoin Coreのピア排除ロジックの理解に焦点を当てています。

インバウンドとアウトバウンドピアの選択: エクリプス攻撃に対する我々の主な防御はどっちですか？

アウトバウンドピアの選択です。攻撃者は、我々が受け入れるインバウンド接続よりも我々が選択するアウトバウンドピアに与える影響が少ないためです。インバウンドピアの排除は2次保護で、すべてのノードがインバウンド接続を許可する訳ではありません。 ➚
なぜBitcoin　Coreはインバウンド接続を排除するんですか?

ネットワーク内の正直なピアがインバウンドスロットを利用できるようにすることで、新しいノードがそれらへの良好なアウトバウンド接続を確立できるようにします。そうしないと、不正なノードは新しいノードにアウトバウンド接続を利用できるようにし、できるだけ多くのインバウンド接続を占有することで、より簡単に新しいノードを攻撃できるようになります。 ➚
スロットを解放する必要がある場合、Bitcoin Coreはどのインバウンドピアを排除するかどうやって決定するんですか？

最大28のピアは、低遅延、ネットワークグループ、新しい有効なトランザクションやブロックの提供、その他いくつかの偽造が困難な基準に基づいて排除から保護されています。一部のオニオンピアを含め、最も長く接続されている残りの半分が保護され、残っているものの内、接続数が最も多いネットワークグループの最年少メンバーが切断対象として選択されます。攻撃者がノードを分断するためには、これらの特性のすべてにおいて、正直なピアよりも優れている必要があります。 ➚

リリーとリリース候補

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

● Bitcoin Core 0.21.0rc5はこのフルノード実装の次のメジャーバージョンとそれに関連するウォレットと他のソフトウェアのリリース候補（RC）です。 Jarol Rodriguezはリリースの主な変更点を説明し、テストを支援する方法を提案するRC testing guideを作成しました。
● LND 0.12.0-beta.rc5はこのLNノードの次のメージャーバージョンの最新のリリース候補です。このリリースではanchor outputをコミットメントトランザクションのデフォルトとし、そのサポートをwatchtowerの実装に追加し、コストを削減し安全性を向上させています。このリリースでは、PSBTの作成と署名のための一般的なサポートも追加され、いくつかのBug Fixが含まれています。

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

今週のBitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、 libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、 Bitcoin Improvement Proposals（BIP）、およびLightning BOLTsの注目すべき変更点。

● Bitcoin Core #18077は、一般的な自動ポートフォワードプロトコルNAT-PMP (Network Address Translation Port Mapping Protocol)のサポートを導入しています。 -natpmp設定パラメータを付けて起動されたBitcoin clientは、NAT-PMP対応ルーターのリスニングポートを自動的に開きます。 NAT-PMPのサポートは、複数のセキュリティ問題によりBitcoin Core 0.11.1以降無効化されていた既存のUPnP (Universal Plug and Play)のサポートと並行して追加されています。UPnPとは対照的に、NAT-PMPはXML解析の代わりに固定サイズのUDPパケットを使用するため、リスクが少ないと考えられています。この変更により、NAT-PMPの後方互換性がある後継である PCP (Port Control Protocol)のサポートが追加されます。
● Bitcoin Core #19055は、今後のPRで予定されている機能に使用できるようMuHashアルゴリズムを追加しています。 newsletter 123で取り上げたように、MuHashはローリングハッシュアルゴリズムで、オブジェクトのセットのハッシュダイジェストを計算し、アイテムが追加・削除された際に効率的に更新することが可能です。これは、2017年にPieter Wuilleによって提案され、Bitcoin Core #10434で実装された全UTXOセットのダイジェストを計算するためにMuHashを使用するというアイディアを復活させるものです。 UTXOセットの統計用のインデックス作成の進捗を追跡し、assumeUTXOアーカイブの検証を容易にすることに興味がある人のために、メタPRBitcoin Core #18000にプロジェクトの進捗と今後の手順が記載されています。
● C-Lightning #4320では、invoiceRPCにcltvパラメーターが追加され、ユーザーやプラグインがインボイスのmin_final_cltv_expiryフィールドを設定できるようになりました。
● C-Lightning #4303では、hsmtoolが標準入力（stdin）でパスフレーズを取得し、コマンドラインで指定されたパスフレーズを無視するよう更新されています。