今週のニュースレターでは、ディスクリプターで使用不可能な鍵を参照するためのBIPドラフトの発表と、 実装でPSBTv2がどのように使用されているかの調査、新しいオフチェーンDLCプロトコルについて先週の説明の訂正を掲載しています。 また、サービスやクライアントソフトウェアの変更や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの最近の変更など恒例のセクションも含まれています。

ニュース

  • ● ディスクリプター内の使用不可能な鍵用のBIPドラフト: Andrew Tothは、 ディスクリプター内の使用不可能なことが証明可能な鍵を参照するための BIPのドラフトをDelving Bitcoinと Bitcoin-Devメーリングリストに投稿しました。 これは以前の議論に続くものです（ニュースレター #283参照）。 NUMS（nothing up my sleeve）ポイントとも呼ばれる、使用できないことが証明可能な鍵を用いるのは、 特にTaprootの内部鍵と関係しています。内部鍵を使用したkeypath支払いができない場合、 Tapleafを使用した（例：Tapscript）scriptpath支払いのみが可能です。

    この記事の執筆時点では、BIPドラフトのPRで活発な議論が行われています。

  • ● PSBTv2統合テスト: Sjors Provoostは、 PSBTバージョン2（ニュースレター #141参照）のサポートを実装したソフトウェアに関する質問を Bitcoin-Devメーリングリストに投稿しました。これは、 Bitcoin CoreでそれをサポートするためのPRのテストのためです。 PSBTv2を使用しているソフトウェアの最新のリストは、Bitcoin Stack Exchangeで確認できます。興味深い回答が2つありました:

    • ● マークル化されたPSBTv2: Salvatore Ingalaは、 Ledger Bitcoin Appは、PSBTv2のフィールドをマークルツリーに変換し、 そのルートのみをLedgerハードウェア署名デバイスに送信すると説明しています。 特定のフィールドが必要な場合は、適切なマークルプルーフと一緒に送信されます。 これによりデバイスは、メモリの制約がある中、メモリ上にPSBT全体を保持することなく、 各情報を独立して検証できます。PSBTv2では、未署名のトランザクションの各パーツが 個別のフィールドに分離されているため、このようなことが可能です。 元のPSBTフォーマット（v0）では、追加のパース処理が必要でした。

    • ● サイレントペイメントとPSBTv2: サイレントペイメントを定義するBIP352は、 PSBTv2のBIP370仕様に明示的に依存しています。Andrew Tothは、 サイレントペイメントでは、すべての署名者がPSBTを処理するまで、 使用するアウトプットスクリプトが分からないため、 v2のPSBT_OUT_SCRIPTフィールドが必要であると説明しています。

  • ● オフチェーンDLCに関する訂正: 先週のニュースレターでオフチェーンDLCについて説明した際、 開発者conduitionが提案した新しいスキームと、 以前公開され実装されたオフチェーンDLCスキームを混同していました。 これらには重要で興味深い違いがあります:

    • ● ニュースレター#174と#260で言及されている DLCチャネル プロトコルは、LN-Penaltyのコミット＆リボークに似た仕組みを使用します。 参加者は、署名により新しい状態に コミット し、古い状態がオンチェーンで公開された場合に、 その古い状態が取引相手によって完全に使用されることになるシークレットを公開することで古い状態を リボーク します。これにより、参加者間の相互作用を通じてDLCを更新することができます。 たとえば、アリスとボブは、以下のようなことを行います:

      1. 1ヶ月後のBTC/USD価格のDLCに直ちに合意します。

      2. 3週間後、2ヶ月のBTC/USD価格のDLCに合意し、前のDLCを取り消します。

    • 新しい DLCファクトリー プロトコルは、コントラクトが満了した時点で、 両参加者がオンチェーンで状態を公開する機能を自動的に取り消します。 これは、コントラクトのオラクルのアテステーションがシークレットとして機能し、 オンチェーンで公開された場合に、取引相手がプライベートな状態を完全に使用できるようにするためです。 事実上、これは古い状態を自動的にキャンセルし、ファクトリーの開始時に、 それ以上のやりとりをすることなく、連続したDLCに署名できるようにします。 たとえば、アリスとボブは、以下のようなことを行います:

      1. 1ヶ月後のBTC/USD価格のDLCに直ちに合意します。

      2. また、2ヶ月後のBTC/USD価格に直ちに合意しますが、トランザクションのタイムロックにより 1ヶ月後まで公開できません。これを3ヶ月め、4ヶ月めと繰り返すことができます。

    DLCチャネルプロトコルでは、アリスとボブは最初のコントラクトを取り消す準備ができるまで2つめのコントラクトを作成できません。 その時点になったら、両者のやりとりが必要です。DLCファクトリープロトコルでは、 ファクトリー作成時にすべてのコントラクトを作成でき、それ以降のやりとりは必要ありません。 ただし、どちらの参加者も、現在安全で公開可能なバージョンをオンチェーンに移行することで、 一連のコントラクトを中断することができます。

    ファクトリーの参加者が、コントラクトの確立後に対話可能な場合は、コントラクトを延長できますが、 以前署名されたすべてのコントラクトが満了するまで、別のコントラクトや別のオラクルを使用することはできません（オンチェーンに移行しない限り）。 この欠点は解消できるかもしれませんが、これは現時点では、 お互いの取り消しによっていつでも任意のコントラクトの変更が可能なDLCチャネルプロトコルと比べて、 対話性が低下することになるトレードオフです。

    先週のニュースレターで私たちの間違いについてお知らせいただき、 質問に辛抱強く答えてくださったconduitionに感謝します。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

リリースとリリース候補

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

  • ● BTCPay Server 2.0.6には、「自動ペイアウトプロセッサを使用した オンチェーンでの払い戻し/プル支払いを使用するマーチャントのためのセキュリティ修正」が含まれています。 また、いくつかの新機能とバグ修正も含まれています。

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

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #31397は、欠落した親トランザクションを提供できる可能性のあるピアを追跡し、 使用することでオーファンの解決プロセスを改善します。 これまでは、解決プロセスは、オーファントランザクションを最初に提供したピアのみに依存していました。 ピアが応答しなかったり、notfoundメッセージを返した場合、再試行の仕組みはなく、 結果としてトランザクションのダウンロードに失敗する可能性が高くなっていました。 新しいアプローチでは、帯域幅効率や検閲耐性および効率的な負荷分散を維持しながら、 すべての候補ピアから親トランザクションをダウンロードしようとします。 これは特に、1P1C（one-parent one-child）パッケージリレーにとって有益で、BIP331の受信者主導の先祖パッケージリレーの舞台を整えるものです。

  • ● Eclair #2896では、将来のSimple Taproot Channelの実装の準備として、 従来の2-of-2のマルチシグの代わりに、ピアのMuSig2部分署名を保存できるようにしました。 これを保存することで、ノードは必要な時に、コミットメントトランザクションを一方的にブロードキャストすることができます。

  • ● LDK #3408では、BOLTs #1149で定義されているように BOLT12で非同期支払いをサポートするために、 ChannelManagerに静的インボイスとそれに対応するオファーを作成するためのユーティリティが導入されています。 インボイスリクエストに対応するために受信者がオンラインである必要がある通常のオファー作成ユーティリティとは異なり、 新しいユーティリティは頻繁にオフラインになる受信者に対処します。このPRでは、 静的インボイスの支払い関して不足しているテストも追加され（ニュースレター#321参照）、 受信者がオンラインに戻った際にインボイスリクエストを取得できることが保証されます。

  • ● LND #9405では、ProofMatureDeltaパラメーターを設定可能にしました。 このパラメーターは、チャネルアナウンスがゴシップネットワークで処理されるまでに必要な 承認数を決定するものです。デフォルト値は6です。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 （ニュース レターが公開された翌日の）木曜日の15:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議 論は録画もされ、ポッドキャストページからご覧いただけます。