Bitcoin Optech Newsletter #374

Oct 3, 2025

今週のニュースレターでは、Bitcoinのコンセンサスルールの変更に関する議論の要約や、新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、恒例のセクションが含まれています。

ニュース

今週は、どの情報源からも重要なニュースは見つかりませんでした。

コンセンサスの変更

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

● スクリプトを復元するためのBIPドラフト: Rusty Russellは、新しいTapscriptバージョンで、スクリプトの機能を復元する提案の概要と、様々な段階にある４つのBIP（1、2、3、4）を Bitcoin-Devメーリングリストに投稿しました。Russellは以前にもこれらのアイディアについて講演や記事を書いています。この提案は、簡単に言うと、より範囲を限定した提案で必要とされるトレードオフの一部を回避しながら、 Bitcoinに（コベナンツの機能を含む）プログラムの拡張を取り戻すことを目的としています。
- ● スクリプト実行時制約用のvaropsバジェット: 最初のBIPはかなり完成度が高く、 Segwitのsigopsバジェットに似たコストメトリクスをほぼすべてのスクリプト操作に割り当てることを提案しています。スクリプトのほとんどの操作では、コストは単純な実装により opcode実行中にノードのRAMに書き込まれるデータのバイト数に基づきます。sigopsバジェットとは異なり、各opcodeのコストは、入力のサイズに依存します。これが「varops」と名付けられた理由です。この統一コストモデルにより、現在ノードを過剰なスクリプト検証コストから保護するために使われている多くの制限を、実用的なスクリプトでは到達不可能またはほぼ不可能なレベルまで引き上げることができます。
- ● 無効化されたスクリプト機能の復元（Tapscript v2）: 2つめのBIPも、（参照実装を除いて）かなり完成度が高く、Bitcoinネットワークを過度なスクリプト検証コストから保護するために 2010年に削除されたopcodeの復元について記述しています。 varopsバジェットが導入されることで、これらのopcode（またはその更新版）をすべて復元でき、その制限を引き上げることができ、数値を任意の長さにすることができます。
- ● OP_TX: 3つめのBIPは、新しい汎用イントロスペクションopcodeの提案です。 OP_TXにより、呼び出し元はトランザクションのほぼすべての要素をスクリプトスタックに取得できるようになります。支払いトランザクションへの直接のアクセスを可能にすることで、このopcodeはOP_TEMPLATEHASHやOP_CHECKTEMPLATEVERIFYなどの opcodeで可能なあらゆるコベナンツ機能を実現します。
- ● Tapscript v2用の新しいopcode: 最後のBIPは、Bitcoinが最初にローンチされた際に欠けていた、またはその時点では必要なかった機能を補完するする新しいopcodeを提案しています。たとえば、 TaptreeやTaprootアウトプットを操作する機能を追加することは、Bitcoin導入時には必要ありませんでしたが、スクリプトが復元された世界では、これらの機能を持つことも理にかなっています。Brandon Blackは、 Taprootアウトプットを完全に構築するために必要なopcodeが不足していることを指摘しました。提案されたopcodeのうち2つ（OP_MULTIとOP_SEGMENT）は、専用の完全なBIPが必要になりそうです。
OP_MULTIは、標準のスタックアイテム数よりも多くのアイテムで動作できるように、後続のopcodeを変更します。たとえばスクリプトで可変数のアイテムを加算することが可能になります。これにより、スクリプト内でループ構造やOP_VAULTスタイルの遅延チェックの必要性を回避しながら、値のフロー制御や同様のロジックが可能になります。

OP_SEGMENT（が登場した場合）は、OP_SUCCESSの動作を変更します。 OP_SUCCESSが登場した場合、スクリプト全体が成功するのではなく、セグメント（スクリプトの開始からOP_SEGMENTが登場し、スクリプトの終了）で区切られた部分のみが成功します。これにより、OP_SEGMENTを含む必須のプレフィックスと、信頼できないサフィックスを持つスクリプトが可能になります。

リリースとリリース候補

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

● Bitcoin Core 30.0rc2は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。バージョン30リリース候補のテストガイドをご覧ください。
● bdk-wallet 2.2.0は、ウォレットアプリケーション構築に使用されるこのライブラリのマイナーリリースです。アップデート適用時にイベントを返す新機能や、永続性テストのための新しいテスト機能の導入およびドキュメントの改善が含まれています。
● LND v0.20.0-beta.rc1は、この人気のLNノード実装の新バージョンのリリース候補です。複数のバグ修正、再起動時のノードアナウンス設定の永続化、新しいnoopAddHTLCタイプ、BOLT11インボイスでのP2TRフォールバックアドレスのサポート、実験的なXFindBaseLocalChanAliasエンドポイントおよび、その他多くの変更が導入されています。

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

最近の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 #33229は、プロセス間通信（IPC）（ニュースレター #369参照）における自動マルチプロセス選択を実装し、 IPC引数が渡されたり、IPC設定がされた場合に、ユーザーが起動時に-mオプションを指定する必要がなくなりました。この変更により、ブロックテンプレートの作成、管理、送信を行う外部のStratum v2サービスとBitcoin Coreの統合が簡単になります。
● Bitcoin Core #33446は、getblockコマンドとgetblockheaderコマンドの応答に targetフィールドを追加した際（ニュースレター #339参照）に発生したバグを修正しました。これまでは常に先端のターゲットを誤って返していましたが、要求されたブロックのターゲットを返すようになりました。
● LDK #3838は、既にサポートしているlsp_trusts_clientモデルに加えて、 BLIP52 (LSPS2)（ニュースレター #335参照）で定義されている JITチャネル用のclient_trusts_lspモデルもサポートするようになりました。新しいモデルでは、LSPは、受信者がHTLCの請求に必要なプリイメージを公開するまで、オンチェーンファンディングトランザクションをブロードキャストしません。
● LDK #4098は、BOLTs #1289で提案された仕様変更に合わせて、スプライシングトランザクションのchannel_reestablishフローにおける next_funding TLVの実装を更新します。このPRは、ニュースレター #371で取り上げられたchannel_reestablishに関する作業に続くものです。
● LDK #4106は、非同期支払いの受信者に代わってLSPが保持するHTLCが、 LSPがHTLCを検出できないために開放されないという競合状態を修正します。これは、 HTLCがpre-decodeマップからpending_intercepted_htlcsマップに移動される前に、 LSPがrelease_held_htlcオニオンメッセージ（ニュースレター #372および#373参照）を受信した場合に発生していました。 LDKは、HTLCが適切に検出され開放されることを確実にするために、後者のマップだけでなく両方のマップをチェックするようになりました。
● LDK #4096は、ピア毎のアウトバウンドゴシップキューのサイズ制限を24メッセージから128KBに変更しました。特定のピアのキューに現在格納されているバイト数の合計がこの制限を超える場合、そのピアへの新しいゴシップの転送はキューが空になるまでスキップされます。この新しい制限により、転送の失敗が大幅に減少します。特に、メッセージのサイズが変化する場合に有効です。
● LND #10133は、指定されたSCIDエイリアス（ニュースレター #203参照）のベースSCIDを返す実験的なXFindBaseLocalChanAlias RPCエンドポイントを追加します。このPRはまた、エイリアスの作成時に逆マッピングを永続化するようにエイリアスマネージャーを拡張し、新しいエンドポイントを有効にします。
● BDK #2029は、CanonicalView構造体を導入しました。これは、特定のチェーンの先端におけるウォレットのTxGraphを一度だけ正規化します。このスナップショットは、後続のすべてのクエリに適用され、呼び出しのたびに再度正規化を行う必要がなくなります。正規化を必要としていたメソッドには現在CanonicalViewと同等のものがあり、誤りのあるChainOracleを引数とするTxGraphメソッドは削除されました。 BDKにおける以前の正規化の作業については、ニュースレター#335および#346をご覧ください。
● BIPs #1911では、BIP21がBIP321に置き換えられたことが示され、 BIP321のステータスがDraftからProposedに更新されました。 BIP321は、Bitcoinの支払い指示を記述するための最新のURIスキームを提案しています。詳細は、ニュースレター #352をご覧ください。