今週のニュースレターでは、手数料の引き上げ方法の研究に関する投稿と、 Bitcoin Core PR Review Clubミーティングのまとめや、 Bitcoinソフトウェアの最新のリリースおよびリリース候補、 人気のあるインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションを掲載しています。

ニュース

  • ● 手数料の引き上げ方法の研究: Antoine Poinsotは、VaultやLNのようなコントラクトプロトコルで使用されている 事前署名されたトランザクションの手数料の引き上げ方法を選択する際に、 開発者が考慮しなければならないいくつかの懸念事項についての詳細な説明をBitcoin-Devメーリングリストに投稿しました。 特に、Poinsotは、参加者が2人より多いマルチパーティプロトコルのスキームについて検討しています。 このようなスキームでは現在のCPFP carve outを利用したトランザクションリレーポリシーが機能せず、 トランザクションのPinningに対して脆弱な可能性がある トランザクションの置換の仕組みを使用する必要があります。 また、彼の投稿には、先行研究されたアイディアのいくつかを調査した結果も含まれています。

    手数料の引き上げが確実に機能することは、ほとんどのコントラクトプロトコルの安全性を確保するための要件であり、 まだ包括的な解決策がない問題です。この問題の研究が続けられているのは心強いことです。

Bitcoin Core PR Review Club

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

Treat taproot as always activeは、Marco FalkeによるPRで、 Taprootのデプロイ状況に関わらず、Taprootを使用するトランザクションアウトプットを標準とするものです。

  • トランザクションがTaprootのインプットを使用する際に、チェックするmempoolのバリデーション関数はどれですか？ このPRではその関数をどう変更していますか？

    関数はAreInputsStandard()です。 このPRでは、関数の最後の引数bool taproot_activeを削除し、 Taprootのアクティベーション状態に関係なくv1 segwit (taproot)の支払いに対してtrueを返します。 これまでは、Taprootのアウトプットが見つかっても、taproot_activeがfalseであれば、この関数はfalseを返していました。 例えばノードがまだ初期ブロックダウンロード中でTaprootをアクティベーションする前のブロックを同期中の場合など。 ➚

  • この変更による理論的な問題はありますか？ウォレットのユーザーが、資金を失う可能性がありますか？

    この変更により、ウォレットはいつでも、つまりTaprootが有効でなくv1 segwitのアウトプットを誰もが勝手に使用できる場合でも、 Taprootのdescriptorをインポートすることができます。 これは、Taprootがまだ有効でなくてもTaprootのアウトプットでビットコインを受け取ることができることを意味します。 もし、チェーンが709,632より前のブロックに再編成された場合、 マイナー（もしくは非標準トランザクションを承認させることができる人）はそれらのUTXOを盗むことができます。 ➚

  • 理論的には、Taprootを決して有効にしない、もしくは異なるブロック高で有効にするmainnetのチェーンが存在する可能性はありますか？

    どちらも可能です。もし、（Taprootのロックイン前にフォークするような）とても大きな再編成が発生した場合、 デプロイプロセスが繰り返されます。この新しいチェーンでは、 Taprootのシグナルを送るブロックの数が閾値に達しなければ、（まだ有効な）チェーンではTaprootは有効になりません。 最小のアクティベーションブロック高の後、かつタイムアウトの前に閾値に達した場合は、 Taprootはそれ以降のブロック高で有効にできます。 ➚

リリースとリリース候補

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

  • ● BDK 0.14.0は、ウォレット開発者向けのこのライブラリの最新リリースです。 トランザクションへのOP_RETURNアウトプットの追加が簡単になり、 Taproot用のbech32mアドレスへの支払いの送信の改善が含まれています。

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

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

  • ● Bitcoin Core #23155は、dumptxoutset RPCを拡張し、 chainstateスナップショット（UTXOセット）のハッシュと、その時点までのチェーン全体のトランザクション数を追加しました。 この情報をchainstateと一緒に公開することで、他の人がgettxoutsetinfoRPCを使って検証することができ、 提案されているassumeUTXOを使ったノードのブートストラップで利用できます。

  • ● Bitcoin Core #22513では、walletprocesspsbtがPSBTをファイナライズせずに署名できるようになりました。 これは複雑なScriptの場合に、例えば、署名者にアリスのみを必要とするフォールバックScriptと、 アリスを含む複数の署名者を必要とする通常のScriptの２つのパスを持つTapscriptでは、この機能が便利です。 アリスが署名する場合、フォールバックScriptのパスでPSBTのファイナライズを遅らせ、 代わりにアリスの署名を含むPSBTを構成し、PSBTを他の署名者に渡して彼らが署名するのを待つのが最善です。 このシナリオでは、すべての署名が作成された後で最終的なパスが決定されます。

  • ● C-Lightning #4921では、onionメッセージの実装を、 ルート・ブラインディングとonionメッセージの仕様の最新の更新に合わせて更新しています。

  • ● C-Lightning #4829では、BOLTs #911で提案されているLNプロトコルの変更に対する 実験的なサポートを追加しています。これにより、 ノードはIPアドレスやTorのオニオンサービスアドレスに代わってDNSアドレスを配信できます。

  • ● Eclair #2061では、onionメッセージの初期サポートを追加しています。 ユーザーは、onionメッセージをリレーするためにoption_onion_messages機能を有効にすることができ、 sendonionmessage RPCを使ってonionメッセージを送信できます。 受信したonionメッセージの処理とルート・ブラインディングはまだ実装されていません。

  • ● Eclair #2073では、BOLTs #906のドラフトで定義されているオプションのチャネルタイプを調整する feature bitのサポートを追加しています。 これは先週のLNDによる同じドラフト機能の実装に対応しています。

  • ● Rust-Lightning #1163では、リモートパーティがdust limit以下のチャネル・リザーブを設定できるようになりました。 ゼロにすることも可能です。最悪の場合、これによりローカルノードは、 完全にキャパシティを使用済みのチャネルからコストをかけずに資金を盗もうと試みることが可能になります。 ただし、リモートパーティがチャネルを監視している場合、そのような試行は失敗します。 デフォルトでは、ほとんどのリモートノードは適切なチャネル・リザーブを設定することで、 このような試みを阻止しますが、一部のLightningサービスプロバイダー（LSP）は、 ユーザーにより良い体験を提供するために（チャネル内の資金を100%使用できるように）、 チャネルリザーブを低くしたりゼロにするのに使用します。 リモートノードのみがリスクを取るため、ローカルノードがそのようなチャネルを受け入れることに問題はありません。