今週のニュースレターでは、BIP340署名の完全な集約に関するBIPドラフトについて掲載しています。 また、サービスやクライアントソフトウェアの最近の更新や、新しいリリースおよびリリース候補の発表、 人気のあるBitcoin基盤ソフトウェアの注目すべき更新など恒例のセクションも含まれています。

ニュース

• ● BIP340署名の完全な集約に関するBIPドラフト: Fabian Jahrは、 BIP340署名の完全な集約に関する新しいBIPドラフトについて、Bitcoin-Devメーリングリストに 投稿しました。これはDahLIAS集約署名スキームの標準（ニュースレター #351 参照）で、 複数の署名を1つの集約署名にまとめるプロセスを記述しています。集約後の署名のサイズは、 署名者の数にかかわらず64 byteです。ただし、このプロトコルは対話型であり、 すべての署名者の協力が必要で、通信の複雑さを軽減するために信頼不要なコーディネーターの存在を伴います。 コーディネーターの役割は、プロセスに参加する署名者のうち誰でも担うことができます。

  このプロセスは2つのラウンドに分かれています:

  1. 各署名者は、シークレットnonce（secnonce）と公開nonce（pubnonce）を計算して署名セッションを開始します。 pubnonceはコーディネーターに送信され、コーディネーターはそれらを集約し（aggnonce）、 その結果を他の情報とともに署名者に送り返します。

  2. 各署名者は、秘密鍵、secnonce、署名対象のメッセージ、および提供された情報を使用して部分署名を計算します。 その後、部分署名はコーディネーターに送信され、コーディネーターはそれらを1つの64 byteの署名に集約します。

  Jahrによると、この提案の応用先として考えられるものの1つがクロスインプット署名集約（CISA）です。 これはBitcoinのコンセンサスの変更であり、複数のインプットを持つトランザクションのサイズ、 ひいてはオンチェーン手数料を削減するものです。ただし、このコンセンサス変更は現在のBIPの範囲外であると著者は明記しています。

  このBIPドラフトは現在BIP459と呼ばれており、BIPs #2210で議論が進められ、コミュニティからのフィードバックを募っている段階です。

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

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

• ● Wasabi Wallet 2.8.0のリリース: Wasabi Wallet 2.8.0は、コンパクトブロックフィルターを P2Pネットワークから直接ダウンロードするようになり、これまで必要だった中央集権的なバックエンドサーバーを排除しました。 このリリースではほかにも、coinjoin実行中に受取人に直接支払う機能、 1 sat/vbyte未満の手数料率のサポート、 支払いバッチ処理などの機能が追加されています。

• ● Coinswap v0.2.2のリリース: Coinswap v0.2.2は、coinswapプロトコル実装（ニュースレター #338 参照）に、 マルチトランザクションスワップ、否認可能性の証明、マーケットプレイスの改善を追加しました。 このリリースには、SpiralのオープンソースかつAIを活用したセキュリティスキャナーである Loupeを用いて実施されたセキュリティ監査で指摘された問題の修正も含まれています。

• ● Go言語向けsecp256k1ライブラリの発表: Alloczは、C言語との相互運用が有効な場合はlibsecp256k1のバインディングを使用し、 そうでない場合は純粋なGo実装にフォールバックすることで、 Goのクロスコンパイル機能を維持するGoライブラリを発表しました。 著者の報告によると、ECDSAおよびSchnorr署名の検証時間は、 純粋なGo実装と比較して70%短縮されるとのことです。

• ● ASMapダッシュボードの発表: Joris Strakeljahnは、ASMapデータのリリース履歴（ニュースレター #394 参照）を追跡する ASMapダッシュボードを発表しました。 このダッシュボードでは、リリースごとにどれだけのアドレス空間が事業者間で移動したか、 また、データが古くなるにつれて各リリースが実際に観測されたBitcoinノードをどの程度カバーしているかなどを確認できます。

• ● Wavelengthアルファ版のリリース: Lightning Labsは、Wavelengthのアルファ版を発表しました。 これは、BOLT11 LNインボイスの支払いと受け取り、Arkに似た決済レイヤーを使用したオフチェーン送金のバッチ処理、 Lightning Labsのインフラを通じた流動性の確保を行うためのツールキットです。 アルファ版はsignetとtestnetで利用可能です。

リリースとリリース候補

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

• ● Core Lightning v26.06.6は、このLNノード実装のメンテナンスリリースです。 本リリースでは、バンドルされているpyln-protoライブラリのcoincurve依存関係を更新して Pythonビルド環境の問題を修正し、既存チャネルのファンディングアウトポイントを再利用するチャネルを拒否するチェックを追加しています。

• ● Bitcoin Inquisition 29.4は、提案中のソフトフォークやその他の主要なプロトコル変更を実験するために設計された signet用のフルノードのリリースです。Bitcoin Core 29.4をベースにしており、 実験的に有効化されたソフトフォーク提案のセットに、BIP446（OP_TEMPLATEHASH）のアクティベーションを追加しています。 これは、支払いトランザクションのハッシュをスタックにプッシュする提案中のTapscript opcodeです （ニュースレター #365 参照）。

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

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

• ● Bitcoin Core #35215は、インメモリUTXOキャッシュ（CCoinsMap）のルックアップを高速化します。 COutPointキーのハッシュに使用されていた関数SipHash-2-4を、 より高速で専用に設計されたSipHashの変種であるSipHasher13UJに置き換えることで実現しています。 各コインは、そのtxidとアウトプット番号を組み合わせたキーで検索され、 すべてのルックアップでそのキーがハッシュ関数を通過します。SipHash-2-4は、 コインの32 byteのtxidを4つの64 bitの断片に分けて処理するため、 1つのアウトポイントのハッシュに14回の内部ラウンドを要します。一方SipHasher13UJは、 txid全体を1回の256 bitステップで取り込み、より少ないラウンドで処理するため、ラウンド数は5回に削減されます。 著者の報告によると、独立したベンチマークではハッシュのスループットが約2倍になり、 chainstateの再インデックス処理では約5%の時間短縮が見られたとのことです。

• ● Bitcoin Core #35766は、DNSシードおよびコンパイル時に組み込まれた固定シードから取得したアドレスに最初に接続する際に、 BIP324 v2 P2Pトランスポートをデフォルトで有効にします。 BIP324の実験的サポートはBitcoin Core 26.0で導入され、27.0でデフォルトで有効化されました。 これらのシードメカニズムはサービスフラグなしでアドレスを提供するため、 Bitcoin Coreは従来、そのピアをv1のみとして扱い、ノードの最初の自動接続では暗号化トランスポートが試行されませんでした。 新しいSeedsAssumedServiceFlags()関数は、これらのアドレスに対してNODE_P2P_V2を想定するようになりました。 この想定が特定のピアに対して誤っていた場合、ノードは単純にv1を使用して再接続します。 -seednodeオプションによる接続とアドレス取得は、すでにデフォルトでv2が試行されるようになっています。

• ● BIPs #2075は、BIP174におけるPSBTの結合方法の記述を明確化します。 この仕様は、独立して更新されたPSBTの結合は無条件に順序に依存しない（順序を入れ替えても結果が変わらない）と主張していましたが、 これは参加者がそれぞれ異なるフィールドを追加する場合にのみ当てはまることでした。 2つのPSBTが同じキーに異なる値を持つ場合、結合処理を行う側（combiner）はどちらかの値を選択するか、 結合を拒否する可能性があるため、仕様には、この場合の結果は可換ではないことが明記されるようになりました。

• ● BIPs #2204は、ドラフト段階のBIP440およびBIP441「Great Script Restoration」の仕様（ニュースレター #400 参照）を更新しています。 スタック要素のbyte長を次の8 byte境界に切り上げるwordspan記法を導入し、 多数のオペレーションコスト計算式が見直されました。具体的には、 データを64 bitワード単位で処理する操作のコストはwordspanに基づいて計算される一方、 正確なbyte単位で動作する操作は引き続きbyte長に基づいて計算されるようになります。 この更新では、OP_RIGHTの定義の修正や、他のいくつかのopcodeのコストと範囲チェックの仕様も明確化されています。

• ● Core Lightning #8935は、置換トランザクションがすでに承認された後でも、 ノードがトランザクションを繰り返しRBFしてしまう可能性のあるバグを修正しています。 CLNは保留中のトランザクションを、元のtxidをキーとするoutgoing_tx_mapに格納しますが、 より高い手数料のバージョンが作られるたびに、キーを変更せずにトランザクションオブジェクトだけを置き換えます。 ブロックごとに実行されるrebroadcast_txs()ループは、マイニングされることのない古い元のtxidを使用して承認を確認していたため、 最新のトランザクションが承認済みであっても、再ブロードキャストと置換のロジックを呼び出し続けていました。 txidはハッシュテーブルのキーとして機能しており、その場で更新できないため、 修正後のループでは反復処理のたびに現在のトランザクションのtxidを計算し、 それを承認チェックに使用するようになりました。

• ● Core Lightning #9324は、v26.04以降に存在していた Renepayのリグレッション（ニュースレター #263 参照）を修正しています。 このリグレッションにより、CLTVの有効期限が本来あるべき高さよりも約1ブロック分先にずれたHTLCが構築されていました。 Renepayのルートデータは、すでに各ホップのCLTV値に現在のブロック高を組み込んでいましたが、 route_sendpay_request()がルートをsendpayに渡す際にブロック高をもう一度加算していたため、 有効期限が実質的に2倍になっていました。その結果、転送ノードがexpiry_too_farでオニオンを拒否する可能性がありました。

• ● libsecp256k1 #1765は、BIP352 サイレントペイメントで定義された 楕円曲線演算を実装するオプションのsilentpaymentsモジュールを追加します。 スキャン機能はフルノードに限定されています。送信者向けには、送信者のインプットの秘密鍵、 トランザクションの最小のアウトポイント、受信者が公開しているスキャン用公開鍵と支払い用公開鍵を組み合わせて、 トランザクションが支払うべきアウトプットの鍵を導出する関数が1つ用意されています。 受信者向けには、フルノードによるスキャンで、トランザクションのアウトプットのうちどれが受信者のものであるかを検出し、 それらを支払いに使用するために必要な調整値（tweak）を返します。 この処理は受信者のスキャン用の秘密鍵と支払い用公開鍵のみから行われるため、 支払い用の秘密鍵はオフラインのままにしておくことができます。ラベルを管理する関数も別途用意されています。 ラベルはBIP352のオプション機能で、受信者がアドレスの識別可能なバリエーションを導出して、 着金を区別したり、自身のお釣りをマークしたりすることを可能にします。 軽量クライアント向けのスキャンのサポートは後続のPRに持ち越されました。

• ● Rust Bitcoin #6317は、コンパクトブロックリレーのデコード処理を更新し、 BIP152で要求されているとおり、ブールのアナウンスフィールドが厳密に 0または1でないsendcmpctメッセージを拒否するようにします。これまでは、 Rust Bitcoinはこのフィールドを非ゼロ判定でデコードしており、 任意の非ゼロ値をtrue（高帯域モード）として受け入れていました。このPRは、Bitcoin Coreにおける同等の堅牢化 （ニュースレター #412 参照）を反映したものです。

• ● BTCPay Server #7457は、BIP329 JSON Lines形式でウォレットラベルをインポートする機能を追加し、 既存のエクスポート機能を補完します。これまでは、別のサーバーに移行する際にラベルは事実上失われており、 SparrowやEnvoyのようなBIP329対応ウォレットが生成したラベルファイルはまったく読み込めませんでした。 このインポーターは、その形式のtx、addr、outputレコードを読み込み、 BTCPayのトランザクション、アドレス、UTXOオブジェクトにマッピングし、適用できないレコードはスキップします。

• ● BLIPs #71は、BLIP32にdnssec_errorレスポンスを追加します。 BLIP32は、DNSSECのクエリと証明をライトニングのオニオンメッセージで伝送することで、 BIP353の人間が読み取り可能な支払い名（human-readable payment names）を解決するプロトコルです（ ニュースレター #306 参照）。これまでは、このプロトコルにはdnssec_queryと dnssec_proofしか定義されておらず、応答できないリゾルバーがそのことをリクエスト元に伝える標準化された方法がなかったため、 リクエスト元は待ち続けることになっていました。新しく追加された最終ホップTLV（タイプ 65550）には、 クエリされたdomain_nameが含まれるほか、definitely_unresolvableというブール値が含まれています。 リゾルバーは、NXDOMAINや署名されていない名前などの恒久的な失敗の場合はこのブール値をセットし、 一時的な障害の可能性があるその他の失敗の場合はセットしません。

もっと知りたいですか？

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