en | ja | es | cs | hi | zh | de | fr | pt

Bitcoin Optech Newsletter #361

Jul 4, 2025

今週のニュースレターでは、LNにおけるOnionメッセージリレーで使用されるネットワーク接続とピア管理を、 HTLCリレーで使用されるものと分離する提案を掲載しています。また、Bitcoinのコンセンサスの変更に関する議論や、人気のBitcoinインフラストラクチャソフトウェアの最近の更新など、恒例のセクションも含まれています。

ニュース

● OnionメッセージとHTLCリレーの分離: Olaluwa Osuntokunは、ノードがOnionメッセージのリレーと、 HTLCのリレーに、それぞれ別の接続を使用できるようにすることについて Delving Bitcoinに投稿しました。直接リレーの場合のように（ニュースレター #283および#304参照）、現在でも別々の接続が可能な場合もありますが、Osuntokunは、分離した接続を常にオプションとして利用可能にし、ノードが支払いのリレーに使用するピアのセットとは異なるOnionメッセージ用のピアのセットを持てるようにすることを提案しています。彼は、この代替アプローチを支持するいくつかの論点を挙げています: 関心事をより明確に分離できること、ノードはチャネルピアよりも高密度なOnionメッセージピアを安価にサポートできること（チャネルの作成にはコストがかかるため）、分離によりプライバシー向上のための鍵ローテションを導入できること、 HTLCコミットメント通信プロトコルによってブロックされる必要がないためOnionメッセージの配信速度が向上する可能性があること。 Osuntokunは、提案されたプロトコルについて、詳細な情報を提供しています。

回答した開発者の何人かが懸念していたのは、Onionメッセージのネットワークが、過剰な数のピアによるノードへのフラッディングをどのように防ぐかという点でした。現在のOnionメッセージの実装では、各ノードは通常、チャネルパートナーとの接続のみを保持しています。チャネルに資金を提供するUTXOの作成には費用（オンチェーン手数料と機会費用）がかかり、ノードとチャネルパートナーに固有のものです。つまり、1つのUTXOに対して1つの接続が確立されます。仮に、Onionメッセージの接続がオンチェーン資金で裏付けられる場合でも、 1つのUTXOですべての公開LNノードへの接続を確立できます。つまり、1つのUTXOで数千の接続が確立されるということです。

少なくとも1人の回答者はOsuntokunの提案を支持していましたが、これまでのところ複数の回答者がサービス拒否リスクへの懸念を表明しています。この記事の執筆時点では、議論は継続中でした。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション

● PTLCにおけるCTV+CSFSの利点: 開発者たちは、さまざまな展開済みおよび想定されるプロトコルにおける OP_CHECKTEMPLATEVERIFY (CTV)と OP_CHECKSIGFROMSTACK (CSFS)、あるいはその両方による利点について、以前の議論（ニュースレター #348参照）を続けました。特に興味深いのは、Gregory SandersがCTV+CSFSについて「たとえ LN-Symmetry自体が採用されなくても、CTV+CSFSは LNをPTLCに更新するのを加速させるでしょう。再バインド可能な署名は、プロトコルを積み重ねる際の負担を大幅に軽減します」と述べています。 Sjors Provoostが詳細を尋ねたところ、Sandersは返信で PTLCのLNメッセージの変更に関する以前の研究（ニュースレター #268参照）のリンクを提供し、「現在のプロトコルでもPTLCは決して不可能ではないが、再バインド可能な署名があれば大幅にシンプルになる」と付け加えました。

Anthony Townsは、さらに次のように言及しました。「PTLCでの開示をmusig 2-of-2（オンチェーンでは効率的）と組み合わせて行うためのツールや標準も不足しています。また、（x CHECKSIGVERIFY y CHECKSIGのような）一般的なトランザクションの署名でさえも同様です。[…]これには、musig2用のアダプター署名が必要ですが、それは仕様には含まれておらず、secp256k1の実装から削除されました。効率は低くなるものの別にアダプター署名として実現することは可能ですが、 Schnorr署名用の単純なアダプター署名さえsecp256k1では利用できません。これらは実験的なsecp256k1-zkpプロジェクトにも含まれていません。[…] ツールが準備されていれば、PTLCのサポートが追加される可能性はありますが[…] 暗号関連の標準化と洗練に注力するほどの優先度が高いと考える人はいないと思います。[…] CAT+CSFSが利用可能であればツールの問題は回避できますが、オンチェーンの効率性は犠牲になります。[…]CSFSのみが利用可能な場合は、相手方が署名に必要なRの値を選択するのを防ぐためアダプター署名を使用する必要があり、同様のツールの問題が引き続き発生するでしょう。これらの問題は、 Gregory Sandersが説明した更新の複雑さやピアプロトコルの更新とは無関係です。」
● Vaultアウトプットスクリプトディスクリプター: Sjors Provoostは、 Vaultを使用するウォレットのリカバリー情報をアウトプットスクリプトディスクリプターを使って指定する方法を Delving Bitcoinに投稿しました。特に、James O’Beirneの simple-ctv-vault概念実証実装（ニュースレター #191参照）で提供されているような OP_CHECKTEMPLATEVERIFY (CTV)ベースのVaultに焦点を当てました。

Provoostは、Salvatore Ingalaの「私の見解では、ディスクリプターはこの目的には適用さないツールです」というコメントを引用しました。 Sanket Kanjalkarは現在のスレッドでこの意見に同意しましたが、回避策を発見しました。 Kanjalkarは、資金をより一般的なディスクリプターにデポジットし、そこからCTV Vaultに移動させる、CTVベースのVault版について説明しました。これにより、知識の浅いユーザーが資金を失う可能性のある状況を回避できるだけでなく、標準的なディスクリプターへのすべての資金が毎回同じ設定でVaultに移動されることを前提としたディスクリプターの作成が可能になります。これによりCTV Vaultディスクリプターは、ディスクリプター言語に無理な変更を加えることなく、簡潔で完全なものになります。
● BitVMにおけるCTV+CSFSの利点に関する議論の続き: 開発者たちは、 OP_CHECKTEMPLATEVERIFY (CTV)および OP_CHECKSIGFROMSTACK (CSFS) opcodeの利用により、「BitVMのトランザクションサイズを約1/10に削減」し、非対話型のペグインを可能にする方法について、以前の議論（ニュースレター #354参照）を続けました。 Anthony Townsは、当初提案されたコントラクトの脆弱性を指摘し、彼と他の開発者たちは回避策を説明しました。CTVではなく提案中の OP_TXHASHを使用する利点が追加で議論されました。Chris Stewartは、 Bitcoin Coreのテストソフトウェアを使って、議論されたアイディアのいくつかを実装し、議論の該当部分を検証し、レビュー担当者に具体的な例を提供しました。
● CTVとCSFSに関する公開書簡: James O’Beirneは、 Bitcoin-Devメーリングリストに公開書簡を投稿しました。これには（本稿執筆時点で）66名の署名が寄せられており、その多くはBitcoin関連プロジェクトのコントリビューターです。この書簡は「Bitcoin Coreのコントリビューターに対し、今後6ヶ月以内に OP_CHECKTEMPLATEVERIFY (CTV)と OP_CHECKSIGFROMSTACK (CSFS)のレビューと統合を優先するよう要請」しています。このスレッドには60件以上の返信が寄せられています。いくつかの技術的なハイライトは次のとおりです:
- ● レガシーサポートに関する懸念と代替案: BIP119は、witness script v1（Tapscript）とレガシースクリプトの両方でCTVを定義しています。Gregory Sandersは、「レガシースクリプトのサポートは[…]レビューの対象領域を大幅に拡大する一方で、プロトコルの機能向上やコスト削減の効果は不明です」と述べています。 O’Beirneは、レガシースクリプトのサポートで場合によっては約8vbyteを節約できる可能性があると返信しましたが、 Sandersはこの節約をwitness scriptで可能にする彼の以前のP2CTV（pay-to-CTV）提案と概念実証の実装をリンクしました。
- ● CTVのみのVautlサポートの限界: 署名者のJameson Loppは、「Vaultに最も関心がある」と述べ、 CTV Vaultが提供する特性、現在事前署名トランザクションを使って導入可能なVaultとの比較、（特にコンセンサスの変更を必要とする高度なVaultと比較して）セキュリティが実質的に向上するかどうかについて議論を始めました。この議論による主な要点は以下のとおりです:
  - ● アドレス再利用の危険性: 事前署名VaultもCTV Vaultもどちらも、ユーザーがVaultアドレスを再利用できないようにする必要があり、そうしないと資金が失われる可能性があります。これを実現する方法の1つは、Vaultに資金をデポジットするのに2つのオンチェーントランザクションが必要になる 2段階のVault手順です。追加のコンセンサスの変更を必要とする高度なVaultはこの問題を持たず、再利用されたアドレスへのデポジットも可能です（ただし、当然ながらプライバシーは低下します）。
  - ● ステージング資金の盗難: 事前署名VaultもCTV Vaultも認可された引き出しの盗難が可能です。たとえば、Vaultユーザーのボブがアリスに1 BTC支払うとします。事前署名VaultとCTV Vaultでは、ボブは以下の手順で支払いを行います:
    - 自分のVaultから1 BTC（場合によっては手数料も）をステージングアドレスに引き出します。
    - Vaultで定義された時間待機します。
    - 1 BTCをアリスに送金します。
    マロリーがボブのステージング鍵を盗んだ場合、引き出しが完了してからアリスへのトランザクションが承認されるまでの間に、マロリーは1 BTCを盗むことができます。しかしマロリーが引き出し用の鍵を盗んだとしても、ボブは保留中の引き出しを中断し、超安全な鍵（または複数の鍵）で保護された安全なアドレスに資金をリダイレクトできるため、マロリーはVaultに残っている資金を盗むことはできません。
    
    より高度なVaultでは、ステージングの手順は不要です。ボブの引き出しは、アリスまたは安全なアドレスのいずれかにしか送れません。これにより、マロリーは引き出しと支払いの間で資金を盗むことができなくなります。
  - ● 鍵の削除: 事前署名Vaultに対するCTVベースのVaultの利点の1つは、事前署名済みのトランザクションセットのみが利用可能なオプションであることを保証するために、秘密鍵を削除する必要がないことです。しかし、Gregory Maxwellは、トランザクションに署名した直後に鍵を削除し、ユーザーに秘密鍵を公開しないソフトウェアを設計するのは簡単だと指摘しています。現在、これを直接サポートするハードウェア署名デバイスは確認されていませんが、少なくとも1つのデバイスがユーザーの手動操作によりこれをサポートしています。しかし、（私たちの知る限り）現在、テスト用であってもCTVをサポートするハードウェアはありません。より高度なVaultはCTVのキーレスの利点を共有しますが、ソフトウェアとハーウェアへの統合も必要になります。
  - ● 静的な状態: 事前署名Vaultに対するCTVベースのVaultの利点の1つは、静的バックアップからウォレットを復元するために必要なすべての情報（アウトプットスクリプトディスクリプターなど）を計算できる可能性があることです。しかし、事前署名された状態の非決定論的なパーツをオンチェーントランザクション自体に保存することで静的バックアップを可能にする事前署名Vaultに関する研究も既に行われています（ニュースレター #255参照）。 Optechは、より高度なVaultであれば静的な状態から復元できると考えていますが、本記事の執筆時点では検証できていません。
- ● Bitcoin Coreコントリビューターからの回答: この記事の執筆時点で、 Optechが現在アクティブなBitcoin Coreコントリビューターと認識している4名が、メーリングリストの書簡に回答しました。彼らは次のように述べています:
  - ● Gregory Sanders: 「この書簡は技術コミュニティからのフィードバックを求めるものであり、これは私からのフィードバックです。何年も更新されていない未展開のBIPは、一般的に健全な提案の兆候ではなく、細心の注意を払ってきた人からの技術アドバイスを拒否する根拠にはなりません。私はこの枠組み、この提案への変更の基準を重大な破壊のみに引き上げること、そしてBIP119を現状のまま期限付きで終了させることに反対します。私は依然として（機能的な意味で）CTV＋CSFSは検討に値すると考えていますが、これはBIP119を頓挫させる確実な方法です。」
  - ● Anthony Towns: 「私の見解では、 CTVの議論は重要なステップを逃しており、それらのステップを踏む代わりに、推進派は少なくとも3年間、世論の圧力を利用して「早期導入」を強制しようとし続けています。私は、CTV推進派が見落としていると思われるステップを踏めるよう支援してきましたが、建設的な成果は得られず、沈黙や侮辱を受けるだけでした。少なくとも私の立場からすると、これはインセンティブの問題を悪化させているだけで、解決にはつながっていないように思います。」
  - ● Antoine Poinsot: 「この書簡の影響は、予想どおり、この提案（あるいはより広義には、この一連の機能）の進捗に大きな後退をもたらしました。この状況からどのように立て直すかは分かりませんが、誰かが立ち上がり、コミュニティからの技術的なフィードバックに実際に対応し、（実際の）ユースケースを示す作業が不可欠です。前進するには、客観的かつ技術的な強力な議論に基づいて合意形成する必要があります。多くの人が関心を表明するだけで、誰も行動を起こさず、提案の前進を支援しないという状況ではだめです。」
  - ● Sjors Provoost: 「私自身の動機についても少し触れさせてください。 Vaultは、この提案によって可能になる機能の中で、個人的に取り組む価値があると感じている唯一の機能のように思います。 […]つい最近まで、Vaultの勢いはOP_VAULTにあり、そのためにはOP_CTVが必要になるように思えました。しかし、単一の目的のopcodeというのは理想的なではないため、このプロジェクトは進展が無いように思えました。 […]一方で、CTV + CSFSには反対しません。これらが有害だという主張は聞いたことがありません。 MeVilの可能性がほとんどないので、他の開発者がこれらの変更を慎重に開発して展開することも想像できます。私はそのプロセスを注視するだけです。私が反対するのは、共同署名者のPaul Sztorcが提案したような、 Pythonベースの代替実装とアクティベーションクライアントです。」
- ● 署名者の声明: 書簡の署名者もその後の声明で彼らの意図を明確にしました:
  - ● James O’Beirne: 「署名した全員が、CTV+CSFSについて、早期のレビュー、統合、そしてアクティベーション計画を明確に確認したいと考えています。」
  - ● Andrew Poelstra: 「書簡の初期のドラフトでは、実際の統合、さらにはアクティベーションまでを求めていましたが、私はいずれの初期ドラフトにも署名しませんでした。優先順位と計画に関する表現（そして、ある種の要求ではなく「敬意ある依頼」）へと弱められた後、ようやく署名しました。」
  - ● Steven Roose: 「この書簡は単にCoreコントリビューターに対し、この提案をある程度の緊急性を持って議題に載せることを求めているだけです。脅しや厳しい言葉もありません。これまでこの提案に関する他の議論に参加したCoreコントリビューターはごくわずかだったため、 Coreコントリビューターにこの議論における立場を表明してほしいという意思を伝えるのが適切な次のステップだと思いました。私は、独立したアクティベーションクライアント含むアプローチには強く反対しており、このメールの趣旨は、プロトコルアップグレードの展開にCoreが関与することを望むという私たちの考えと一致している思っています。」
  - ● Harsha Goli: 「ほとんどの人が署名したのは、次のステップがどうあるべきか全く分からなかったからです。トランザクションコミットメントに対するプレッシャーがあまりにも大きかったため、（署名付きの書簡という）悪手でも、何もしないよりましだと判断したのです。（私の業界調査で促進された）書簡が送られる前の話し合いでは、署名者の多くから、この文書について警告する声しかありませんでした。実際、この書簡を明確に良いアイディアだと考えた人は一人もいません。それでも署名しました。そこにシグナルがあるんです。」
● OP_CATが可能にするWinternitz署名: 開発者のConduitionは、提案中のOP_CAT opcodeと他のスクリプト命令を用いて、 Winternitzプロトコルを使用した量子耐性署名をコンセンサスロジックで検証するプロトタイプ実装をBitcoin-Devメーリングリストに投稿しました。 Conduitionの実装では、鍵、署名、スクリプトで約8,000 byteを必要とします（その大部分はwitnessディスカウントの対象となり、オンチェーンweightは約2,000 vbyteになります）。これは、Jeremy Rubinが以前提案した OP_CATベースの別の量子耐性ランポート署名方式よりも、約8,000 vbyte小さいものです。
● ポスト量子リカバリーのためのコミット/開示機能: Tadge Dryjaは、高速な量子コンピューターが支払いに使用されようとしているアウトプットをリダイレクト（盗むことが）できる場合でも、量子脆弱な署名アルゴリズムを使用してUTXOを使用できるようにする方法を Bitcoin-Devメーリングリストに投稿しました。これにはソフトフォークが必要で、Tim Ruffingによる以前の提案（ニュースレター #348参照）の変形版です。

Dryjaのスキームでアウトプットを使用するには、支払人は3つのデータへのコミットメントを作成します:
1. 資金を管理する秘密鍵に対応する公開鍵のハッシュh(pubkey)。これを アドレス識別子 と呼びます。
2. 公開鍵と支払人が最終的にブロードキャストしたいトランザクションのtxidとハッシュh(pubkey, txid)。これを シーケンス依存証明 と呼びます。
3. 最終的なトランザクションのtxid。これを コミットメントtxid と呼びます。
これらの情報はいずれも、基礎となる公開鍵を明かすものではありません。この方式では、 UTXOを管理する人物だけが公開鍵を知っていると仮定します。

3つのパーツで構成されるコミットメントは、量子安全なアルゴリズムを用いたトランザクション（たとえば、 OP_RETURNアウトプット）でブロードキャストされます。この時点で、攻撃者は同じアドレス識別子と異なるコミットメントtxidを使って、攻撃者のウォレットに資金を送金する独自のコミットメントをブロードキャストしようとする可能性があります。しかし、攻撃者はベースとなる公会鍵を知らないため、有効なシーケンス依存証明を生成することはできません。これは完全な検証ノードですぐには分かりませんが、UTXOの所有者が公開鍵を明かした後で、攻撃者のコミットメントを拒否することができます。

コミットメントが適切な深さまで承認された後、支払人はコミットメントtxidと一致する完全なトランザクションを公開します。フルノードは、公開鍵がアドレス識別子と一致し、txidと組み合わせてシーケンス依存証明と一致することを検証します。この時点で、フルノードはそのアドレス識別子に対する最も古い（最も深く承認された）コミットメント以外をすべて削除します。有効なシーケンス依存証明を持つそのアドレス識別子で最初に承認されたtxidのみが、承認済みトランザクションとして解決できます。

Dryjaは、このスキームをソフトフォークとして展開する方法、コミットメントバイトを半分に削減する方法、そして現在のユーザーとソフトウェアがこのスキームの使用に備えてできること、そしてスクリプト型およびスクリプトレスマルチシグのユーザーにとってのこのスキームの制限についてさらに詳しく説明しています。
● トランザクションスポンサーシップをサポートするOP_TXHASHの変形版: Steven Rooseは、 OP_TXHASHの変形版であるTXSIGHASHについてDelving Bitcoinに投稿しました。これは、64 byteのSchnorr署名を拡張し、署名がトランザクション（または関連トランザクション）のどのフィールドにコミットするかを示すbyteを追加します。 Rooseは、OP_TXHASHに以前提案されたコミットメントフィールドに加えて、効率的な形式のトランザクションスポンサーシップ（ニュースレター #295参照）を使用してブロック内のそれより前のトランザクションに署名をコミットできると指摘しています。そして、このメカニズムのオンチェーンコストを既存のCPFPや以前のスポンサーシップの提案と比較して分析し、次のように結論づけています: 「 [TXSIGHASH]スタッキングでは、スタックされた各トランザクションの仮想byteコストは、スポンサーを含まない元のコストよりもさらに低くなる可能性があります。[…] さらに、すべてのインプットは単純なkey-spendであるため、CISAが導入されれば集約できます。」

この記事の執筆時点では、この投稿への返信はありませんでした。

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

最近の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 #32540では、/rest/spenttxouts/BLOCKHASH RESTエンドポイントが導入されました。このエンドポイントは、指定されたブロックで使用されたトランザクションアウトプット（prevouts）のリストを、主にコンパクトなバイナリ（.bin）形式、また.jsonおよび.hex形式で返します。これまでも、/rest/block/BLOCKHASH.jsonエンドポイントで同様の処理が可能でしたが、この新しいエンドポイントでは、JSONシリアライゼーションのオーバーヘッドが排除されるため、外部のインデクサーのパフォーマンスが向上します。
● Bitcoin Core #32638では、ディスクから読み込まれたブロックが期待されるブロックハッシュと一致することを確認する検証機能が追加され、これまで検出できなかったビット腐敗やインデックスの混同を検出できるようになります。 Bitcoin Core #32487で導入されたヘッダーハッシュキャッシュのおかげで、この追加チェックには実質オーバーヘッドはありません。
● Bitcoin Core #32819および#32530は、 32-bitシステムにおいて、起動パラメーター-maxmempoolと-dbcacheの最大値をそれぞれ 500MBと1GBに設定しました。このアーキテクチャのRAMの総上限は4GBであるため、新しい制限を超える値を設定すると、メモリ不足（OOM）が発生する可能性があります。
● LDK #3618は、非同期支払い用のクライアント側のロジックを実装し、オフラインの受信ノードが常時オンラインのヘルパーLSPノードを使用してBOLT12 オファーと静的インボイスを事前に準備できるようにします。このPRは、ChannelManager内に、オファーとインボイスを構築、保存および永続化する非同期受信オファーキャッシュを導入します。また、LSPとの通信に必要な新しいOnionメッセージとフックを定義し、ステートマシンをOffersMessageFlowに組み込みます。