今週のニュースレターでは、DLCの仕様に重大な変更をするための提案と、 BIP32のシードのみで閉じたLNチャネルの復元を可能にするためのオプションの検討、 ステートレスなLNインボイスを生成するアイディアについて掲載しています。 また、Bitcoin Stack Exchangeからの人気のある質問と回答や、 Taprootアクティベーションの準備のためのアイディア、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● DLCの仕様の重大な変更に関する議論: Nadav Kohenは、DLC-devメーリングリストに、 既存のアプリケーションとの互換性を損なう可能性のあるいくつかの変更を加えたDLCの仕様の更新について投稿しました。 彼は2つの選択肢を提示しました: 必要に応じて仕様を更新し、どのバージョンを実装しているかアプリケーションに知らせる方法と、 混乱を最小限に抑えるためにいくつかの変更をまとめて行う方法です。 DLCのソフトウェアに取り組んでいる開発者からのフィードバックを求めています。

  • ● シードのみを使用したLNのクローズトランザクションの復元に関する課題: Electrum Walletの開発者であるghost43は、 ウォレットのチャネルクローズトランザクションのためにブロックチェーンをスキャンする際のいくつかの課題について、 Lightning-Devメーリングリストに投稿しました。 BIP32スタイルのHD鍵生成のみでウォレットを復元する際に、 新しいanchor outputプロトコルを処理する際の特定の問題についてです。 ghost43はいくつかの可能性のあるスキームを分析し、 現在Eclairで使用されているスキームが、可能な最良なものとして推奨されています。 また、チャネル開設プロトコルの若干の変更を厭わなければ、さらなる改善が期待できます。

  • ● ステートレスなLNインボイスの生成: Joost Jagerは、Lightning-Devメーリングリストに、 認証されていないユーザーに対してLNインボイスを生成するアプリケーションに対するサービス拒否攻撃の可能性について投稿しました。 具体的には、攻撃者は無制限の数のインボイスを要求することができ、 インボイスの生成サービスはそれらが期限切れになるまで保存する必要があります。 Jagerは、データ量の少ないインボイスの場合は、インボイスを作成後すぐに忘れてしまい、 代わりに要求したユーザーにインボイスのパラメーターを与えることができると提案しました。 これらのパラメーターは、支払いと共に送信され、サービスはインボイスを再構築し、支払いを受け入れ、 注文を処理することができます。

    回答者の中には、このアイディアが不要ではないかと懸念する人もいました。 別の方法でアプリにリクエストを殺到させることは可能であり、 それらの問題を解決するためには、インボイスのリクエストの殺到も解決する必要があります。 しかし、このアイディアは有用であると考える人もいました。 このアイディアはプロトコルの変更を必要とせず、 インボイスの生成と再構築を管理するソフトウェア（またはプラグイン）の変更だけで済みます。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

Taprootの準備 #15: まだ必要なsignmessageプロトコル

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

4年以上前にsegwitが有効になって以来、bech32やbech32mアドレスに対して 署名付きテキストメッセージを作成する広く受け入れられた方法はありません。 間違いなく、これは広範なメッセージ署名のサポートが、ユーザーや開発者にとってそれほど重要ではないことを意味し、 そうでなければ、もっと多くの作業がそれに費やされていることでしょう。 しかし、誰もがレガシーアドレスを使い、署名されたメッセージを簡単に交換できた時代から、 Bitcoinウォレットソフトウェアは後退したように感じます。

約2年前にbech32支払いのサポートシリーズで書いた 汎用的なsignmessageソリューションは低迷しており、 プロトコルドキュメントであるBIP322が時折更新されているにもかかわらず （ニュースレター#118および#130参照）、 Bitcoin Coreには採用されませんでした。 それにもかかわらず、私たちはこれ以上の代替案を知らないため、 P2TRウォレットにsignmessageサポートを追加したい開発者にとっては、 BIP322が依然として好ましい選択であるはずです。

実装されている場合、汎用のsignmessageは、P2TRアウトプットに対して、 シングルシグやマルチシグ、または任意のTapscriptを使用して メッセージに署名できるようにします。 また、すべてのレガシーアドレスおよびbech32アドレスとの後方互換性と、 近い将来に想定されている変更（そのうちのいくつかは、今後のTaprootの準備コラムで紹介します）との前方互換性も提供されます。 完全なUTXOセットにアクセスできるアプリケーション（例: フルノード経由）は、 BIP322を使用してリザーブ・プルーフを生成・検証することもできます。 これは、署名者がある時点で一定量のビットコインを管理していたことを証明するものです。

汎用的な署名付きメッセージを作成するためのサポートは、非常に簡単に実装できるでしょう。 BIP322では、仮想トランザクションと呼ばれる技術を使っています。 最初の仮想トランザクションは、存在しない前のトランザクション（txidがすべてゼロのトランザクション）から支払いしようとすることで、 意図的に無効になるように作成されます。この最初のトランザクションは、 ユーザーが署名したいアドレス（スクリプト）に支払い、希望するメッセージのハッシュコミットメントを含みます。 2つめのトランザクションは、最初のトランザクションのアウトプットを使用します。 その支払いの署名およびその他のデータが有効なトランザクションであれば、 メッセージは署名されているとみなされます（ただし、2つめの仮想トランザクションは、 無効なトランザクションを参照しているため、オンチェーンに含めることはできません）。

汎用的な署名付きメッセージを検証することは、多くのウォレットにとって困難です。 任意のBIP322メッセージを完全に検証できるようにするには、 基本的にすべてのBitcoinのコンセンサスルールを実装する必要があります。 ほとんどのウォレットではそれを行っていないため、BIP322ではScriptを完全に検証できない場合に 「不確定」な状態を返すことができます。 実際には、特にTaprootがkeypathの支払いを奨励している場合、それは稀なことかもしれません。 最もよく使われるScriptタイプのいくつかを実装したウォレットであれば、 全UTXOの99%以上の署名付きメッセージを検証することができます。

汎用的なsignmessageのサポートはBitcoinの有用な追加機能になるでしょう。 ここ数年、注意が払われてこなかったことを無視することはできませんが、 これを読んでいるウォレット開発者には、プログラムに実験的なサポートを追加することの検討をお勧めします。 これは、ここ数年ユーザーが失っていた機能をユーザーに提供する簡単な方法です。 BIP322や関連するリザーブ・プルーフの実装に取り組んでいる開発者の方や、 このような機能が有用であると思われるサービスプロバイダーの方は、 info@bitcoinops.orgまでお気軽に連絡いただき、取り組みを調整ください。

リリースとリリース候補

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

  • ● Bitcoin Core 0.21.2は、Bitcoin Coreのメンテナンスバージョンのリリースです。 これには、いくつかのバグ修正と軽微な改善が含まれています。

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

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

  • ● Bitcoin Core #12677では、ウォレットのlistunspent RPCメソッドが返すトランザクションアウトプットに、 ancestorcountおよびancestorsize、ancestorfeesフィールドを追加しました。 トランザクションアウトプットを作成したトランザクションが未承認の場合、これらのフィールドは、 そのトランザクションとmempool内のその未承認の祖先すべての合計カウント、サイズ、手数料を示します。 マイナーはこれらの祖先の手数料率を元にブロックに含めるトランザクションを選択するため、 祖先のサイズや手数料を知ることはトランザクションの承認時間を推定したり、 CPFPやRBFを使ってトランザクションの手数料を引き上げようとする際に役立ちます。

  • ● Eclair #1942では、経路をキャパシティに基づいて部分的に評価されるよう、 経路探索アルゴリズムを設定することができます。 この設定は、ルーティングの成功率を向上させる可能性のある実験的なパラメーターセットとして適用できます。 [編集: この項目は公開後に修正されました。Thomas Huetからの報告に感謝します。]

  • ● LND #5101では、RPCリクエストをサーバーに送信する際に、 それを受信して変更することができるミドルウェアインターセプターを追加しました。 これにより、LNDの外部にロジックを実装して、ユーザーおよび自動化されたアクションを追跡したり影響を与えたりすることができます。 セキュリティの観点から、インターセプトをオプトインする認証トークン（macaroons）を明示的に使用するRPCのみをインターセプトできます。