今週のニュースレターでは、JoinMarketのFidelity bondに関する以前の記事の続きと、 Bitcoin Core PR Review Clubミーティングの概要、 Taprootの準備の提案、リリースおよびリリース候補の発表、 人気のあるインフラストラクチャプロジェクトの注目すべき変更などの恒例のセクションを掲載しています。

ニュース

  • ● Fidelity bondの実装: JoinMarket 0.9.0のcoinjoinの実装には Fidelity bondのサポートが含まれています。 以前ニュースレター #57に掲載したように、 この保証は、JoinMarketシステムのシビル耐性を向上させ、 coinjoin開始者（テイカー）が独自の流動性（メーカー）を選択する能力を高めます。 リリースから数日のうちに、 50 BTCを超える額（現在の価値にして200万USD以上）がタイムロックされたFidelity bondに預け入れられました。

    具体的な実装はJoinMarket独自のものですが、全体的な設計は、 Bitcoin上に構築された他の分散プロトコルにも役立つ可能性があります。

Bitcoin Core PR Review Club

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

Prefer to use txindex if available for GetTransactionは、 Jameson LoppによるPRで、可能な限りトランザクションインデックス（txindex）を利用することで、 GetTransaction（ひいては、ユーザー向けのgetrawtransaction RPC）のパフォーマンスを向上させるものです。 この変更により、txindexを利用可能なノードでトランザクションが含まれるブロックのハッシュを指定して getrawtransactionを呼び出すと著しく遅くなるという予期せぬ性能低下が修正されました。 Review Clubでは、txindexを使用する場合としない場合のトランザクションの取得手順を比較することで、 このパフォーマンス問題の原因を評価しました。

  • GetTransactionがディスクからトランザクションを取得する方法にはどのような方法がありますか？

    トランザクションを取得する方法には、（未承認の場合）mempoolから取得する方法、 ディスクからブロック全体を取得してトランザクションを検索する方法、 txindexを使用してトランザクションをディスクから単独でフェッチする方法があります。 ➚

  • （txindexが有効で）ブロックハッシュが提供されている場合にパフォーマンスが低下するのはなぜだと思いますか？

    参加者は、ブロックのデシリアライゼーションがボトルネックになっているのではないかと推測しました。 ブロック全体をフェッチする場合の固有の処理として、時間はかかりませんが、 トランザクションのリスト全体をリニアに検索する処理があります。 ➚

  • ブロックハッシュでトランザクションを検索する場合、どんな手順になりますか？どのくらいのデータがデシリアライズされますか？

    まず、ブロックインデックスを使用して、ブロックへアクセスする際に必要なファイルとバイトオフセットを見つけます。 その後、ブロック全体をフェッチ、デシリアライズし、一致するものが見つかるまでトランザクションリストをスキャンします。 これには約1〜2MBのデータのデシリアライズが必要です。 ➚

  • txindexを使ってトランザクションを検索する場合、どんな手順になりますか？どのくらいのデータがデシリアライズされますか？

    txindexは、トランザクションIDからファイルと（ブロックインデックスと同様）ブロックの位置、 blk*.datファイル内のトランザクションの開始オフセットまでをマッピングします。 ブロックヘッダーとトランザクションをフェッチ、デシリアライズします。 ヘッダーは80Bで、ブロックハッシュをユーザーに返すことができます（これはtxindexに保存されていない情報です）。 トランザクションはどんなサイズでもいいですが、通常はブロックの数千分の1になります。 ➚

  • このPRの最初のバージョンでは、GetTransactionに誤ったblock_indexが与えられた場合、 txindexを使ってとにかくtxを見つけて返すという動作の変更が含まれていました。 この変更は改善だと思いますか？またこのPRに含めるべきだと思いますか？

    参加者は、便利だが誤解を招くおそれがあり、誤ったブロックハッシュを入力したことをユーザーに通知する方が良いという点で合意しました。 また、パフォーマンスの改善と動作の変更は、別のPRに分けるのが最適であることも指摘されました。 ➚

Taprootの準備 #8: マルチシグのnonce

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

先週のコラムでは、マルチシグについて書き、 MuSig2を使った例を紹介しました。 私たちの説明は技術的には正しいと思われますが、MuSig2に貢献した何人かの暗号技術者は、 私たちが提案した使い方は危険だと心配していました。 私たちは、当面の懸念に対応するため説明を更新し、 その後、この問題をより徹底的に調査しました。 この記事では、マルチシグを安全に実装するための最大の課題であると思われるnonceの再利用の回避について説明します。

Bitcoinで署名を検証するには、署名と署名されたメッセージ（トランザクションなど）、 公開鍵、公開nonceを公開されている方程式に入力します。 この方程式が成立するのは、自分の秘密鍵とnonceの秘密情報を知っている場合だけです。 したがって、成立した方程式を確認した人は、そのメッセージと公開鍵に対する署名が有効であると考えます。

署名とメッセージを方程式に含める動機は明らかです。公開鍵は秘密鍵の代用です。 公開nonceは何のためのものでしょうか？これがなければ、方程式内の秘密鍵以外の値はすべて分かっているため、 基本的な代数を使って未知の1つの値を解くことができます。しかし代数学では、 2つの未知の値を解くことはできません。そのためnonceの秘密の情報は、あなたの秘密鍵を隠す役割をします。 また、公開鍵が署名式の中で秘密鍵の代用となっているように、nonceの公開情報は秘密情報の代用となっています。

ここでいうnonceとは、一度使っただけの数値ではなく一度しか使ってはならない数値のことです。 同じnonceを異なる2つの署名で再利用すると、2つの署名式を組み合わせてnonceを打ち消し、 唯一の残った未知の値であるあなたの秘密鍵を再び誰かが解くことができます。 BIP32標準の導出（非強化導出）を使用している場合、ほとんどのマルチシグウォレットがそうであるように、 1つの秘密鍵が明らかになると、同じBIP32パス内（おそらく他のパスも同様）にある他のすべての秘密鍵も明らかになります。 つまり、100個の異なるアドレスでビットコインを受け取ったマルチシグウォレットは、 署名者がnonceを1つでも再利用すると、それらのアドレスの全てが危険にさらされることになります。

シングルシグのウォレットや、スクリプトベースのマルチシグを使用しているウォレットは、 nonceの再利用を避けるために、nonceを署名しようとしているメッセージに依存させるという 簡単なトリックを使用できます。メッセージに変更があると、nonceも変わるため、nonceが再利用されることはありません。

マルチシグにはこのトリックは使えません。すべての共同署名者は、部分署名だけでなく、 部分公開nonceも提供する必要があります。部分公開nonceは結合されて、集約公開nonceとなり、 署名するメッセージに含まれます。

つまり、トランザクションが同じでも、同じ部分nonceを2回以上使用することは安全ではありません。 2回めの署名の際に、あなたの共同署名者が部分nonceを変更した（集約nonceを変更した）場合、 2回めの部分署名は異なるメッセージに対するものになります。 そうなるとあなたの秘密鍵が明らかになります。 すべての参加者が自分のnonceの秘密を、他のすべての参加者の部分公開nonceに依存させるのは循環的で不可能であるため、 マルチシグでnonceの再利用を避けるための簡単なトリックはありません。

一見すると、これは大きな問題ではないように思えます。 署名者はなにかに署名するたびに、新しいランダムなnonceを生成すればよいのです。 これは思ったより正しく理解するのが難しいものです。少なくとも2012年以降、 ランダムなnonce生成に依存するウォレットでビットコインを失うバグが発見されています。

しかし、たとえウォレットが高品質なランダムnonceを生成したとしても、 各nonceは最大で1回しか使用されないようにしなければなりません。 先週のコラムの原文では、MuSig2と互換性のあるコールドウォレットやハードシェア署名デバイスについて掲載していましたが、 これらのデバイスは最初の実行時に大量のnonceを作成します。 ウォレットやデバイスは、これらのnonceを2つ以上の部分署名で使用されないようにする必要があります。 nonceが使用されるたびにカウンターをインクリメントするだけの簡単なことのように聞こえますが、 外部からの悪意ある介入による影響はもちろんのこと、 ソフトウェアやハードウェアが偶発的に故障する可能性があることを考えると、本当に難しいことです。

ウォレットがnonceの再利用のリスクを減らす最も簡単な方法は、nonceをできるだけ短期間保存することでしょう。 先週の例では、nonceを数ヶ月から数年にわたって保存することを提案しましたが、 これは何か問題が発生する可能性が高いだけでなく、 バックアップや復元、予期せぬ状態になる可能性のある永続的なストレージにnonceを記録する必要があります。 MuSig2を使用する別の方法としては、PSBTを受信したときなど、 必要に応じてnonceを作成する方法です。nonceは必要な短時間だけ揮発性のメモリに保持しておき、 ソフトウェアのクラッシュや電源の喪失など予期せぬ事態が起こった場合には、 自動的に破壊される（再利用できなくなる）ようにしておくことができます。

しかし、この問題に取り組んでいる暗号技術者は、オリジナルのMuSigプロトコル（MuSig1）やMuSig2において、 nonceの再利用を防ぐための確実な方法がないことを非常に懸念しているようです。 MuSig-DN (deterministic nonce)は解決策を提供していますが、 複雑で時間がかかります（アルファ版の実装では、2.9 GHzのIntel i7でnonceの証明を作成するのに約1秒かかり、 それよりもはるかに性能の低い16 MHzのハードウェア署名デイバイスでどれだけ時間がかかるかは不明です）。

マルチシグ署名を実装する方へのアドバイスとしては、時間やリソースに大きな投資をする前に、 IRCの#secp256k1ルームやBitcoinの暗号技術者が集まる他の場所に立ち寄って、 計画を説明することを検討してください。

リリースとリリース候補

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

  • ● C-Lightning 0.10.1は、いくつかの新機能やバグ修正、 （デュアル・ファンディングやOfferを含む） 開発中のプロトコルのいくつかの更新を含むリリースです。

  • ● Bitcoin Core 22.0rc2は、 このフルノード実装と関連するウォレットおよび他のソフトウェアの次のメジャーバージョンのリリース候補です。 この新バージョンの主な変更点は、I2P接続のサポートと、 Torのバージョン2接続のサポートの削除および、 ハードウェアウォレットのサポートの強化などです。

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

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

  • ● Bitcoin Core #21528は、フルノードのリスニングアドレスのP2P伝播の改善を目的としています。 多様なアドレスセットを公開することは、 エクリプス攻撃のようなネットワーク分断からノードを保護するのに重要です。 Bitcoin Coreノードは、10個以下のアドレスを含むアドレスメッセージを受信すると、 それを自身の1〜2つのピアに転送します。これは自身でアドレスを配信するために使用される主な手法であるため、 これらのアドレスを中継しないピアに送信すると、ネットワークを介した伝播が効果的に停止またはブラックホールになります。 悪意あるケースでは、伝播の失敗を防ぐことはできませんが、このパッチは、 block-relay-only接続や軽量クライアントなどの正直なケースのアドレスの伝播を改善します。

    この更新により、addrやaddrv2、getaddrなどのアドレス関連のメッセージが、 接続を介して送信されたかどうかに基づいて、インバウンド接続がアドレス転送候補かどうかを識別します。 この動作の変更は、アドレスメッセージの受信に依存しているものの、 アドレス関連のメッセージを決して開始しないソフトウェアがネットワーク上に存在する場合、 問題となる可能性があります。そのため、作者は、この変更案がマージされる前に、 メーリングリストに投稿したり、 他のオープンソースクライアントを調査して互換性を確認するなど、注意を払いました。

  • ● LND #5484では、すべてのデータを単一の外部Etcdデータベースに保存できるようになりました。 これにより、クラスターのリーダーシップの変更が瞬時に行われるようになり、 高可用性のあるデプロイが改善されます。対応するLNDクラスタリングのドキュメントは、 以前のニュースレター #157でカバーされています。

  • ● Rust-Lightning #1004では、支払いの転送が成功した際の追跡を可能にするPaymentForwardedの新しいイベントを追加しています。 転送が成功するとノードが手数料を得られる可能性があるため、 これによりユーザーの会計記録のためにその収入を追跡することができます。

  • ● BTCPay Server #2730では、インボイス生成時に金額を省略できるようになりました。 これにより、アカウントに補充する際など、オペレーターが金額の選択をユーザーに委譲する際の支払いフローが簡素化されます。