今週のニュースレターでは、ノードがErlayトランザクションリレープロトコルを実装できるようにするBIPの内容、古いバージョンのライトニング実装に影響する脆弱性の開示内容、最近のOptech schnorrおよびtaprootワークショップのトランスクリプトへのリンク、フィールドレポートBitcoin Exchange BTSEがブロックチェーンスペースを節約し、ユーザーの入金の安全性を確保するために使用している技術の一部について紹介します。また、Bitcoinインフラストラクチャプロジェクトに対するいくつかの注目すべき変更点についても説明します。

Action items

今週は特になし。

News

  • ● Erlay互換性を有効にするためのBIPドラフト: reconciliationによるトランザクションリレーのBIPドラフトがErlayの共著者であるGleb NaumenkoによってBitcoin-Devメーリングリストに投稿 されました。現在、ビットコインノードは、新しく表示されたすべてのトランザクションのtxidを各ピアに送信します。その結果、各ノードは、多くの重複したtxidアナウンスを受信します。1日に数万のノード間で数十万トランザクションがやり取りされるビットコインにとっては帯域幅の効率が非常に悪い場合があります。 この問題を以前のNewsletter,で記載した通り、 minisketch-based set reconciliationが解消します。各ノードは短いtxidのセットのsketchを送信できます。受信ピアは、それと自身がすでに知っている短いtxidと組み合わせることで自身が保持していないtxidを知ることが可能になります。 sketchのサイズは、取得する必要があるtxidのサイズとほぼ等しく、txidアナウンスの帯域幅を削減します。 Erlayは、このメカニズムを使用して帯域幅効率とネットワークの堅牢性の最適な組み合わせを実現する方法を提案する提案です。このドラフトBIPでは、ノード間のminisketchベースのセット調整の実装案について記述しており、Erlayの実装のベースとなるでしょう。フィードバックをお持ちの方は誰でも、BIP作成者に個人的に、またはメーリングリストで連絡することをお勧めします。

  • ● 複数のLN実装に影響する修正された脆弱性の開示内容: 数週間前、C-Lightning、Eclair、およびLNDの開発者は、最近のリリースで修正された未公開の問題の発見について発表しました。当時、彼らはユーザーにアップグレードすることを強く奨励し（以前のOptech Newsletter参照）将来的にはその内容開示を約束し、現在は、発見者でありC-Lightning開発者であるRusty Russellによるメール および、LND開発者であるOlaoluwa OsuntokunおよびConner Fromknechtによるブログにより開示がされています。

    簡潔に説明すると、チャネルオープンの際のトランザクションが正しいスクリプト、金額であるチェックが実装されていなかったことが問題のようです。このため、オンチェーンで実際は確認することができない支払いを受け入れられてしまい、詐欺が可能になっておりました。この記事の執筆時点では、Optechは先月の警告の前にこの問題が悪用されたという報告を認識していません。この問題が公開に伴いPR が公開され、このチェックが必要であることを示す仕様が更新されました。

  • ● Optech taproot and schnorr ワークショップ: 先週、Optechはサンフランシスコとニューヨーク市で、Schnorr署名スキームと、提案されたtaproot ソフトフォークなどについて開発者向けのワークショップを開催しました。ニューヨークでのワークショップのトランスクリプトを作成してくれたBryan Bishopに感謝します。我々は近い将来、ブログを通じてビデオやその他の教材を公開する予定です。

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

*Bitcoin Core,LND, C-Lightning, Eclair,libsecp256k1, Bitcoin Improvement Proposals(BIPs), および Lightning BOLTsにおける注目すべき変更点 *

  • ● Bitcoin Core #15558 は、Bitcoin Coreが照会するDNS Seedの数を変更します。DNS Seedは、リスンしているピア（接続を受け入れるピア）のIPアドレスを返すサーバーです。新しく起動されたノードは、DNS Seedを照会して、ピアの初期セットを見つけます。それらのピアは、他の可能なピアについてノードに通知し、ノードはこの情報を後で使用するためにディスクに保存します（再起動後を含む）。理想的には、ノードがDNSシードを照会するのは、それらが最初に開始されたときに1回だけです。実際には、選択した保存済みピアのいずれも十分に迅速に応答しない場合などに後続のスタートアップでクエリを実行することもあります。

    このマージにより、Bitcoin Coreは、すべてではなく、一度に3つのDNSシードのみを照会します。3つのシードは、ノードが少なくとも1つ正直なピア（ビットコインセキュリティの要件として記述されています）に接続することを保証するためにはのに十分なソースの多様性が必要ですが、直接DNS解決を使用する場合、すべてのシードがクエリノードについて学習するわけではありません。照会するシードは、Bitcoin Coreにハードコーディングされたリストからランダムに選択されます。

  • ● LND #3523 3523で特定のオープンチャネルまたはすべてのオープンチャネルで受け入れるHTLCのリサット値の更新が可能になります。

  • ● LND #3505 は、invoiceを7,092バイト（単一のQRコードに収まる最大サイズ）に制限します。invoiceが大きいと、大量のメモリが割り当てられる可能性があります。パッチの作成者がテストした1.7 MBの請求書では、約38.0 MBの割り当てが生成されました。

  • ● Eclair #1097 は、funding pubkeyからchannel keysの導出を開始し、すべてのデータが失われた場合でもEclairがニュースレター＃31 で説明されているData Loss Protection（DLP）スキームを使用できるようにします。これには、ユーザーがチャンネルを開いたノードをリコールし、チャンネルID（公開チャンネルの公開情報）を見つける必要があります。 これは、この変更を実装するソフトウェアのバージョンに更新した後に開かれた新しいチャネルにのみ適用されます。古いチャンネルは影響を受けません。 (注：ニュースレター＃31では、このマージされたPRによってEclairがDLPサポートが追加可能となるであろうと記載していましたが、実際はEclairは既にDLPサポートを持ち、すべてのデータが失われた場合もサポート可能となっておりました。誤記を報告してくださったFabrice Drouinに感謝します。）

  • ● C-Lightning #3057 は、C-Lightningのデータベースマネージャーとしてpostgresの使用を可能にします。

  • ● C-Lightning #3064 は、C-Lightningノードが他のノードからのチャネル更新アナウンスを中継する頻度を減らすために、Newsletter #63 で説明されている変更を行います。これにより、ノードが使用するゴシップ帯域幅が削減されます。