今週のNewsletterでは、BIP340:schnorrのキーと署名の更新案についての説明、フルノード間のスタートアップ機能のネゴシエーションを改善する提案についてフィードバック募集、ハードウェア・ウォレットが破損したナンスを使用して秘密キーを漏らさないために標準化された方法の提案、taprootが安全であるためのハッシュ関数に必要なプロパティの分析についてお送りします。通常セクションであるリリースのお知らせ、Bitcoinインフラストラクチャプロジェクトの主な変更点についてもお送りします。

Action items

今週はなし。

News

  • ● BIP340 schnorrのキーと署名の更新: Newsletter#84の2つの個別項目（1、2）で前述したように、BIP340schnorr署名の更新がいくつか提案されています（これはBIP341taprootにも影響します）。Pieter Wuilleは、公開鍵のどのバリアントをBIP340で使用するかを変更することを提案しています。新しい選択は、鍵の均一性に基づいています。ナンスを生成するための推奨手順が変更されます。ナンス生成に公開鍵が含まれ、利用可能な場合は独立して生成されるランダム性が含まれ、ランダム性を使用して秘密鍵を難読化するステップをナンス生成アルゴリズムに含めるようになります。キーをdifferential power analysisから保護するためです。

これらは重要な変更のため、BIP340のタグ付きハッシュのタグが変更され、以前のドラフト用に記述されたコードで署名を生成すると、提案されたリビジョンでの検証に失敗することが保証されます。Wuilleは、変更に関するコミュニティフィードバックを要求しています。

  • ● 起動時のフルノード間の機能ネゴシエーションの改善: Suhas Daftuarは、新しいピアとの接続を開くためにノードが使用するシーケンスにメッセージを挿入する提案についてフィードバックを求めています。新しいメッセージは、ノードがピアから受信する機能をネゴシエートしやすくします。ここでの課題は、特定のメッセージが特定の順序で表示されなかった場合、Bitcoin Coreの以前のバージョンが新しい接続を終了することです。Daftuarが新しいメッセージを挿入したいのはこの厳密なシーケンスです。提案はP2Pプロトコルバージョンを増やして後方互換性を提供しますが、Daftuarはネゴシエーションメッセージの挿入が問題を引き起こすかどうかについて、フルノードのメンテナーからフィードバックを求めています。問題を認識している場合は、スレッドに返信してください。

  • ● 耐漏出性ナンスプロトコルを標準化する提案: Stepan Snigirev はBitcoin-Devメーリングリストで、ハードウェア・ウォレットがバイアスされたnonceを使用してユーザーの秘密鍵を漏らさないようにするプロトコルの標準化に関する議論を開始しました。この攻撃を防御するための以前に提案されたメカニズムの1つは、sign to contract protocolを使用して、署名がハードウェア・ウォレットのホストコンピューターまたはモバイルデバイスによって選択されたランダム性にコミットすることを確認することです。libsecp256k1の開発者は、既に契約への一般的な署名を有効にすることと、抽出耐性ナンス機能をその上に構築するAPIに取り組んでいます。Snigirevのメールでは、現在推奨されているプロトコルと、それを複数のコンピューターおよび部分署名付きビットコイン・トランザクション（PSBT）に拡張する方法について説明がされています。

  • ● 汎用グループモデルのTaproot: Lloyd Fournierは、2週間前、taprootが安全であるためにtaprootで使用されるハッシュ関数に必要なプロパティを説明する彼のポスターをFinancial Cryptography conferenceに公開しました。これは、以前のAndrew Poelstraによるproofを拡張したもので、ハッシュ関数がrandom oracleとして機能するというより広範な仮定を作成しました。taprootの暗号化セキュリティを評価する人は、Poelstraの証明とFournierのポスターを確認することをお勧めします。

Releases and release candidates

Bitcoinインフラストラクチャの新しいリリースおよびリリース候補。新しいリリースにアップグレードするか、リリース候補のテストを支援することを検討してください。

  • ● LND 0.9.1は新しいマイナーバージョンリリースであり、新しい機能は含まれていませんが、「ノード間で誤った強制終了」を引き起こす可能性があるバグを含むいくつかのバグを修正します。

  • ● Bitcoin Core 0.19.1（リリース候補）

Notable code and documentation changes

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

  • ● Bitcoin Core #17985は、トランザクションがmempoolから拒否された場合でも、ホワイトリストに登録されたピアからのトランザクションを中継するという、デッドコードを削除します。この機能はBitcoin Core 0.13.0で動作を停止しましたが、それが意図的なものなのか偶然なのかは不明です。

  • ● Bitcoin Core #17264は、部分的に署名されたビットコイン・トランザクション（PSBTs）の作成や処理をするRPCのデフォルトを変更し、既知のBIP32HDウォレット派生パスを含めます。これにより、後でPSBTを処理する他のウォレットは、その情報を使用して適切な署名キーを選択したり、おつり用のアウトプットが正しいアドレスに支払うことを確認したりできます。派生パスを非公開のままにしたい人は、 bip32_derivsパラメータを使用して共有を無効にすることができます。

  • ● C-Lightning #3490は、ローカルノードのプライベートキーとユーザー指定のパブリックキーの組み合わせから共有シークレットを取得する「getsharedsecret」RPCを追加します。この共有シークレットは、他の共有シークレットがLNプロトコルで派生するのと同じ方法で派生します（ECDH結果のSHA256ダイジェスト）。他のプログラムが楕円曲線暗号を使用して共有シークレットを派生する方法とは異なる場合があります（例：ECIES）。このRPCは、他のLNノードとの通信を暗号化するプラグインに役立ちます。

  • ● Eclair #1307は、Eclairが使用するパッケージスクリプトを更新し、ソフトウェアの使用に必要なすべてのzipファイルを生成します。この新しい方法により、コアライブラリ（Newsletter#83で報告した）に加えて、決定論的にEclair GUIを構築できます。再現可能なビルドは、ユーザーが実行するソフトウェアが公開レビューされているソースコードに基づいていることを確認するのに役立ちます。

  • ● Libsecp256k1 #710は、テストを支援するためにライブラリに小さな変更を加えます。変更の1つでは、以前に値の範囲を返すことができた関数（文書化された動作とは反対に）は、0または1のみを返すようになりました。少なくとも1つの他のライブラリが古い動作を使用しており、#secp256k1 IRCチャットルームでは、他のプログラムまたはライブラリも古い推奨されない動作を使用している可能性があるという懸念に言及されています。あなたのプログラムが secp256k1_ecdh関数を使用している場合、このPRと関連するrust-secp256k1に対するissueの議論を確認することを検討してください。

  • ● BIPs #886は、BIP340schnorr署名を以下2つの推奨事項で更新します。（1）乱数ジェネレーターが利用可能な場合は常にナンス計算にエントロピーを含めること（2）外部プログラムに配布する前に 、ソフトウェアで作成された署名が有効であることを検証すること（少なくとも追加の計算と遅延が負担にならない限り） これら2つの手順は、再利用されたnonceで無効な署名を取得することにより、攻撃者がユーザーの秘密キーを取得できないようにするのに役立ちます。攻撃の詳細については、Newsletter#83をご覧ください。BIP340のその他の提案された変更については、今週のNewsletterの上記のニュースアイテムをご覧ください。