今週のニュースレターでは、Eclair 0.3.3のリリースの発表、Bitcoin Coreメンテナンス・リリースに対するテスターの公募、taprootおよびtapscriptを試すためのツールへのリンク、事前計算された公開キーを使用したschnorr署名の安全な生成に関する議論の要約、LNファンディング・トランザクションにおけるインタラクティブな構築についてお送りします。また、Bitcoinインフラストラクチャ・プロジェクトの主要な変更についてもお送りします。

Action items

News

  • ● Taprootおよびtapscript実験ツール: Karl-Johan Almは、Bitcoin-Devリストに、tapというコマンドラインツールを使用してtaprootおよびtapscript出力の作成と実行をサポートする彼のbtcdebツールの実験的なブランチについて投稿しました。詳細については、彼の詳細なチュートリアルを参照してください。

  • ● schnorr署名で使用される事前計算された公開キーに関連する安全性の懸念: libsecp256k1 PR #558は、Bitcoin Coreおよび他のいくつかのBitcoinプログラムで使用されるlibsecp256k1ライブラリにBIP340互換のschnorr署名の作成と検証を追加することを提案しています。 BIP340では、署名の検証に使用される公開キーにコミットするために署名が必要であるため、現在提案されている署名関数は、秘密キーを使用して必要な公開キーを算出します。 Gregory Maxwellは、署名を生成するプログラムは通常、適切な公開鍵を既に知っているため、関数が公開鍵をパラメーターとして受け入れることでCPU時間を節約できると指摘しました。

    Jonas Nickは、このアプローチは合理的であると回答しましたが、それを安全に行うには、決定論的ナンスの作成に使用されるデータに公開鍵を含める必要があるとも話しています。それ以外の場合、クラッカーが2つの異なる公開鍵に対して同じ秘密鍵によって作成された2つの署名を取得でき、他のすべてのデータが同じままである場合、知らないうちにナンスを再利用し、クラッカーは秘密鍵を取得してビットコインを盗むことができます。問題への対処についての議論は別の場所で続けられます。

    さらに、公開鍵を検証せずに受け入れる実装が、再利用されたナンスを生成する可能性があることが明らかになったため、Gregory Maxwellは、このリスクに関するed25519実装（これもschnorr署名の派生を使用）をメーリングリストに投稿しました。 Ed25519の共著者であるDaniel Bernsteinは、「障害に対する一般的な防御策は、署名者が各署名を検証することである」と回答しています。これにより、無効な公開鍵が提供されたことが検出され、Bitcoin Coreなどの一部のウォレットは、現在使用されているECDSA署名アルゴリズムに対しても、生成する署名に対してこのチェックを確実に実行します。ただし、このアプローチの演算オーバーヘッドは多くのアプリケーションでは受け入れられない可能性があり、経験の浅い開発者がこのステップを実行することを知らないリスクが残っているため、決定論的ナンスの生成に使用されるデータに公開鍵を含めるというJonas Nickの提案（その後Maxwellが引き継いだ）を使用することが望ましいようです。

    これまでのところ、この問題の直接的な結果としてBIP340に変更は加えられていませんが、決定論的ナンスアルゴリズムに公開鍵を含めるなどの提案された変更が議論されています。

  • ● 代替のXのみのpubkeyタイブレーカー: 上記の問題について議論したように、Pieter Wuilleは、鍵のX座標のみがわかっている場合に使用する公開鍵のバリアントを選択するために使用するアルゴリズムを変更することにより、秘密鍵からの公開鍵の派生をわずかに高速化することを提案しました。（Newsletter #59の32バイトの公開鍵に関する議論を参照）。これは重要な変更であるため、提案は署名の一部を生成するために使用されるタグ付きハッシュも変更します。

    この変更はまだメーリングリストに発表されていません。おそらく、開発者は、事前演算された公開鍵を署名機能に提供する安全性に対処するために、他にどのような変更を同時に行うべきかを評価しているためでしょう。

  • ● LNファンディング・トランザクションのインタラクティブな構築: 現在のLNプロトコルでは、新しいチャネルを開くオンチェーン・トランザクションは、完全に単一のユーザーによって作成されます。これはシンプルであるという利点がありますが、チャネルでの支払いが最初一方向にしか流れないという欠点があります（チャネルに資金を提供したユーザーから他のユーザーへ）。Lisa Neigutは、両当事者がチャネルの開設に資金を提供できるデュアル・ファンディングプロトコルに取り組んでいます。これは、支払いが最初に両方向に流れることができるチャネルを作成し、ネットワークの流動性を改善するのに特に役立ちます。

    ただし、デュアル・ファンディングの提案は複雑であるため、Neigutは今週、Lightning-Devメーリングリストで、この新しいプロトコルの1つの側面を分割するスレッドを立ち上げました。これはLNノードがファンディング・トランザクションを共同で構築する機能です。

    これは以前にセキュリティの改善として説明され（Newsletter #78参照）、Neigutは、コラボレーション・メカニズムがバッチ・クロージング（同時に複数のチャネルを相互にクローズする機能）およびスプライシング（チャネルにおける資金の出し入れを、そのチャネルにある資金に影響を与えずに行う機能）にも影響します。Neigutの提案への返信には以下が含まれます。

    • nLockTimeフィールドの値を直近または今後のブロックの高さに設定してアンチ・フィー・スナイピングを実装する提案。これによりブロックチェーンの再編成を阻害するのに役立ち、トランザクションが既にアンチ・フィー・スナイピングを実装している他のウォレットとのファンディング・トランザクションの作成にも役立ちます（LNDのスイープモード含む。Newsletter #18参照）

    • より広義には、他の共同トランザクション作成システム（コインジョイン・ソフトウェアなど）を使用して、トランザクションのフリー・パラメーター（nVersion、nSequence、nLockTime、インプット順序、アウトプット順序など）に共通の値のセットを実装する提案。これにより、LNファンディング・トランザクションが作成されていることを示す明確なインジケーターが生成されなくなります（特にtaprootが採用された場合、相互ルートLNのクローズトランザクションはシングルシグ支出のように見えるため）。

    • BIP174部分署名ビットコイン・トランザクション（PSBT）を使用して、提案されたトランザクションの詳細を伝達するための提案。 Neigutは、PSBTは「2つのピア間のトランザクション・コラボレーションには少し重すぎる」と考えているとも答えています。

    • マロリーがボブとのデュアル・ファンディング・チャンネルを開くプロセスを開始し、ボブのUTXOのいずれかのIDを受け取った後に取引中止するような行為の回避方法についての議論。ファンディング・トランザクションが完了する前に中止することにより、マロリーはどのネットワークID（ノード）がどのUTXOを所有しているかを費用なしで知ることができます。

      これを修正するための1つの提案では、チャネルを開くことを提案している人（上記例の場合マロリー）がUTXOをすぐに使える状態で提供し、こうした行為にお金（例：取引手数料）がかかるようにする事です。このアプローチの欠点は、提案された構造がブロックチェーン分析によって簡単に識別できるため、デュアル・ファンディング・チャネルがいつ開かれたかを簡単に判断できることです。

      もう1つの提案は、Gregory Maxwellの提案に基づいてJoinMarket用に開発されたPoDLEを使用することです。このプロトコルにより、マロリーなどの取引を開始するユーザーは、誰でもそのUTXOを識別できないようにUTXOにコミットできます。一方ボブなどの参加ユーザーは、ネットワーク（JoinMarketネットワークなど）でコミットメントを公開し、その特定のUTXOを使用している間に誰もマロリーとのセッションを開始しないようにします。次に、ボブはマロリーにUTXOを識別するように依頼し、それが彼女のコミットメントに一致する有効なUTXOである場合、ボブはマロリーに彼のUTXOを開示して、プロトコル（たとえば、コインジョイン）を続行できるようにします。もしマロリーが完了する前にプロトコルを中止すると、以前にネットワークを介して公開されたコミットメントにより、他のユーザーとの新しいセッションを開始してUTXOを識別することができなくなります。マロリーの唯一の選択肢は、新しいUTXOを生成するために自分からコインを使うことです。このプロセスはお金がかかるため、ユーザーを覗き見する事を制限します。（ただし、JoinMarketに実装されているPoDLEでは、デフォルトでマロリーが最大3回再試行できるため、正直なユーザーは、ネットワーク接続の喪失などの偶発的な失敗に対してペナルティを受けません。）要はこのプロトコルをLNに適応させて、どのUTXOがLNユーザーによって制御されているかをクラッカーが知ることを防ごうとしているのです。

Notable code and documentation changes

今週のBitcoin Core、C-Lightning、Eclair、LND、libsecp256k1、ビットコイン改善提案（BIP）、およびLightning BOLTの注目すべき変更点

  • ● Bitcoin Core #16702により、Bitcoin CoreはIPアドレス・プレフィックスではなく オートノマス・システム・ナンバー（ASN）に基づいてピアを選択できます。 ASNに基づいてピアを区別すると、特定のエクリプス・アタック（Erebusアタックなど）を正常に実行することが難しくなる場合があります。この新しい機能はデフォルトで無効になっています。ASNベースのピアリングを利用するには、ユーザーはasmapを使用して生成できるASNテーブルファイルを提供する必要があります。将来のリリースには、Bitcoin Core開発者によって生成およびレビューされるASNテーブルファイルが含まれる可能性があります。このアプローチの詳細については、#bitcoin-core-devのIRCディスカッションの概要をご覧ください。

  • ● Bitcoin Core #17951は、最近のブロックで確認されたトランザクションのローリング・ブルーム・フィルターを保持します。ノードのピアの1つがトランザクションを発信すると、ノードはフィルターに対してトランザクションのtxidをチェックします。一致する場合、ノードはトランザクションのダウンロードをスキップします（既に確認されているため）。これは、トランザクションをダウンロードするかどうかを決定する以前のメカニズムを置き換えます。この以前の方法は、アウトプットが既に使用されている場合、既に確認されたトランザクションを重複してダウンロードしていたので帯域幅を浪費していました。

  • ● C-Lightning #3315は、dev-sendcustommsgRPCおよびcustommsgプラグインフックを追加し、ノードから任意のピアにカスタムネットワーク・プロトコルメッセージを送信できるようにします。この機能は、C-Lightningデーモンによって内部でまだ処理されていないメッセージ、および奇数番号のタイプのメッセージ（it’s ok to be oddルールに従います）でのみ使用できます。注：この機能を、オニオン暗号化された支払い内のネットワークルートを介してチャットメッセージを送信するWhatSatなどのアプリケーションと混同しないでください。このマージされたPRは、ノードの直接ピアへのプロトコルメッセージの送信のみを許可します。

  • ● Eclair #1295では、eclair-coreモジュールを決定論的に構築できます。構築の詳細については、 ドキュメントを参照してください。 ACINQは、Eclair MobileやPhoenixなど、他のソフトウェアを再現可能にビルドできるようにする意向も発表しています。

  • ● Eclair #1287は、マルチパス・ペイメントとトランポリン・ペイメントに関連する費用の追跡を改善するために、データベースにフィールドを追加します。

  • ● Eclair #1278では、Torが独自の認証と暗号化を提供するため、サーバーがTorヒドゥン・サービスとして実行されている場合、Electrumスタイルのブロックチェーン・データサーバーへの接続時にSSLの使用をスキップできます。

Acknowledgments and edits

PoDLEに関するセクションのドラフトをレビューしてくれたAdam Gibsonに感謝します。発行されたテキストに誤りがある場合の責任は全てニュースレター作成者にあります。生成された署名を公開する前に検証することのトレードオフを明確にするために、Pieter Wuilleの提案により、公開後にテキストが追加されました。