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

Bitcoin Optech Newsletter #393

Feb 20, 2026

今週のニュースレターでは、最近のOP_RETURNの使用状況に関するまとめ、コンセンサスを変更することなくコベナンツのような使用条件を強制するプロトコルについて掲載しています。また、サービスとクライアントソフトウェアの最近の更新や、新しいリリースおよびリリース候補の発表、人気のBitcoin基盤ソフトウェアの最近の更新など、恒例のセクションも含まれています。

ニュース

● 最近のOP_RETURNアウトプットの統計: Anthony Townsは、 Bitcoin Core v30.0のリリース（10月10日）以降のOP_RETURNの統計について Delving Bitcoinに投稿しました。このリリースには、 OP_RETURNアウトプットに対するmempoolポリシー制限の変更（複数のOP_RETURNアウトプットの許可、 OP_RETURNアウトプットにおける最大100kBまでのデータの許可）が含まれていました。彼が調査したブロック高の範囲は、915800から936000までで、以下の結果が得られました:
- OP_RETURNアウトプットを含むトランザクション：24,362,310件
- 複数のOP_RETURNアウトプットを持つトランザクション：61件
- OP_RETURNアウトプットのスクリプトの合計サイズが83 byteを超えるトランザクション：396件
- 期間中のOP_RETURNアウトプットのスクリプトデータの合計は473,815,552 byte（そのうち、大きなOP_RETURNSの割合は0.44%）
- OP_RETURNアウトプットでsatsを焼却しているトランザクションは34,283件で、焼却されたsatsの合計は、1,463,488 sats
- OP_RETURNのデータが43〜83 byteのトランザクションは949,003件で、42 byte以下のトランザクションは23,412,911件
Townsはまた、大きなOP_RETURNアウトプットを持つ396件のトランザクションのサイズの頻度分布を示すチャートも掲載しました。これらのトランザクションの50%は、OP_RETURNのデータが210 byte未満でした。また10%はOP_RETURNのデータが10KBを超えていました。

彼はその後、MurchがXで同様の分析とOP_RETURN統計のダッシュボードを公開したこと、 OrangesurfがMempool Research向けにOP_RETURNに関するレポートを公開したことを追記しました。
● Bitcoin PIPEs v2: Misha Komarovは、コンセンサスの変更や楽観的なチャレンジメカニズムを必要とせずに使用条件を強制できるプロトコルであるBitcoin PIPEsについてDelving Bitcoinに投稿しました。

Bitcoinプロトコルは、最小限のトランザクション検証モデルに基づいており、これは使用されるUTXOが有効なデジタル署名によって認可されていることを検証するものです。そこでBitcoin PIPEsは、Bitcoin Scriptで表現される使用条件に依存する代わりに、有効な署名を生成できるかどうかの前提条件を追加します。言い換えれば、秘密鍵が事前に定められた条件に基づいて暗号的にロックされます。条件が満たされた場合にのみ、秘密鍵が明らかになり、有効な署名が提供できるようになります。Bitcoinプロトコルは、 1つのSchnorr署名を検証するだけで済み、条件ロジックはすべてオフチェーンで処理されます。

形式的に、Bitcoin PIPEsは主に2つのフェーズで構成されます:
- ● セットアップ: 標準的なBitcoinの鍵ペア(sk, pk)が生成されます。次にskは、witness encryptionを用いて使用条件ステートメントに基づいて暗号化されます。
- ● 署名: ステートメントにwitness wが提供されます。 wが有効な場合、skが明らかになりSchnorr署名が生成できます。そうでない場合は、 skの復元は計算量的に不可能です。
Komarovによると、Bitcoin PIPEsは、コベナンツのセマンティクスを再現するために使用できます。特に、Bitcoin PIPEs V2は、限定的な使用条件にフォーカスしており、バイナリコベナンツを強制します。このモデルは、有効なゼロ知識証明の提供や、 exit条件の充足、Fraud Proofの存在など、結果がバイナリ（二値）である幅広い有用な条件を自然に捉えます。基本的に、すべての「条件が満たされているか否か？」という単一の問いに帰着します。

最後に、Komarovは新しいopcodeの代わりにPIPEsを活用する方法と、 BitVMプロトコルの楽観的な検証フローを改善するためにPIPEsをどのように活用できるかについて、実際の例を示しました。

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

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

● SecondがhArkベースのArkソフトウェアをリリース: SecondのArkライブラリは、バージョン0.1.0-beta.6で hArk（ハッシュロックArk）を使用するようにアップデートされました。この新しいプロトコルは、ラウンド中のユーザーの同期的な対話要件を排除しますが、それに伴うトレードオフも存在します。このリリースには、互換性を破る変更を含むその他のアップデートも含まれています。
● AmbossがRailsXを発表: RailsXの発表では、LNとTaproot Assetsを使用してスワップやその他のさまざまな金融サービスをサポートするプラットフォームの概要が説明されています。
● Nunchukがサイレントペイメントのサポートを追加: Nunchukが、サイレントペイメントアドレスへの送金のサポートを発表しました。
● Electrumがサブマリンスワップ機能を追加: Electrum 4.7.0では、ライトニング残高を使ったオンチェーン支払い（サブマリンスワップ参照）など、さまざまな機能追加と修正が行われました。
● Sigbash v2発表: Sigbash v2では、MuSig2やWebAssembly（WASM）、ゼロ知識証明を使用し、共同署名サービスのプライバシーを強化しています。詳しくは、 Sigbashに関する以前の記事をご覧ください。

リリースとリリース候補

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

● BTCPay Server 2.3.5は、このセルフホスト型ペイメントソリューションのマイナーリリースです。ダッシュボードに複数の仮想通貨ウォレットの残高ウィジェット、チェックアウト用のカスタムテキストボックス、新しい為替レートプロバイダーが追加され、いくつかのバグが修正されています。
● LND 0.20.1-betaは、この人気のLNノード実装のメンテナンスリリースです。ゴシップメッセージ処理にpanicリカバリー機能を追加し、再編成保護を強化し、 LSP検出ヒューリスティックを実装し、複数のバグと競合状態を修正しています。

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

最近の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 #33965は、起動時の設定-blockreservedweight （ニュースレター #342参照）がマイニングIPCクライアント（ニュースレター #310参照）によって設定された block_reserved_weight値を密かに上書きしてしまうバグを修正しました。今後は、 IPC呼び出し元が後者を設定した場合、それが優先されます。この値を設定しないRPC呼び出し元は、起動時の-blockreservedweight設定が常に適用されます。このPRはまた、 IPC呼び出し元にMINIMUM_BLOCK_RESERVED_WEIGHTを強制し、それを下回る値の設定を防止します。
● Eclair #3248は、HTLCの転送時に両方の選択肢がある場合、パブリックチャネルよりもプライベートチャネルを優先するようになりました。これにより、ネットワークで可視であるパブリックチャネルにより多くの流動性が確保されます。 2つのチャネルが同じ可視性を持つ場合、Eclairは残高がより少ないチャネルを優先するようになりました。
● Eclair #3246は、いくつかの内部イベントに新しいフィールドを追加しました。 TransactionPublishedでは、単一のminingFeeフィールドがlocalMiningFeeと remoteMiningFeeに分割され、計算されたfeerateと、トランザクションを流動性の購入に紐付けるオプションのLiquidityAds.PurchaseBasicInfoが追加されました。チャネルライフサイクルイベントには、チャネルタイプを記述するcommitmentFormatが含まれるようになり、 PaymentRelayedにはrelayFeeが追加されました。
● LDK #4335は、BOLT12オファーを使用したファントムノード支払い（ニュースレター #188参照）の初期サポートを追加しました。 BOLT11版では、インボイスに存在しない「ファントム」ノードを指すルートヒントが含まれ、各パスの最後のホップがステートレスインボイスを使用して支払いを受け入れることができる実際のノードでした。BOLT12版では、単純にオファーに各参加ノードで終端する複数のブラインドパスが含まれます。現在の実装では、複数のノードがインボイスリクエストに応答できますが、結果として生成されるインボイスは応答したノードにのみ支払われます。
● LDK #4318は、ChannelHandshakeLimits構造体からmax_funding_satoshisフィールドを削除し、 wumbo以前のデフォルトのチャネルサイズ制限を事実上撤廃しました。 LDKは、既にデフォルトでoption_support_large_channels機能フラグを通じてラージチャネルのサポートを通知しており、以前の設定と競合することでピアに対して誤ったサポートシグナルを送る可能性がありました。リスクを制限したいユーザーは手動チャネル承認フローを使用できます。
● LND #10542は、ゴシップv1.75（ニュースレター#261および #326参照）をサポートするために、グラフデータベース層を拡張し、 Simple Taproot Channelのチャネルアナウンスを保存および取得できるようになりました。ゴシップv1.75は、バリデーションおよびゴシップサブシステムの完成を待って、ネットワークレベルでは無効のままです。
● BIPs #1670は、Pay-to-Merkle-Root（P2MR）を規定するBIP360を追加しました。これは、P2TRと同様に動作しますがkeypath支払いが削除された新しいアウトプットタイプです。 P2MRアウトプットは、公開鍵ではなくスクリプトツリーのマークルルート（SHA256ハッシュ）に直接コミットするため、暗号学的に意味のある量子コンピューター（CRQC）による長時間露出攻撃に耐性があります。ただし、トランザクションが未承認の間に秘密鍵を復元するような短時間露出攻撃に対する保護には、別途ポスト量子署名の提案が必要です。提案がP2QRHと呼ばれていた頃の以前の記事についてはニュースレター #344を、 P2TSHと呼ばれていた頃の記事はニュースレター #385をご覧ください。
● BOLTs #1236は、デュアルファンディングの仕様を更新し、チャネルの確立中にどちらのノードもtx_init_rbfを送信できるようにしました。これにより、両者がファンディングトランザクションの手数料の引き上げを行えるようになります。これまでは、チャネル開設者のみがこれを行えましたが、この変更により（どちらの側からも既にRBFを開始できる）スプライシングと整合するようになりました。このPRはまた、tx_init_rbfおよびtx_ack_rbfの送信者が以前の試行から少なくとも1つのインプットを再利用することを必須とし、新しいトランザクションがすべての以前の試行を二重使用することを保証します。
● BOLTs #1289は、デュアルファンディングとスプライシングの両方で使用される対話型のトランザクションプロトコルにおいて、再接続時のcommitment_signedの再送方法を変更しました。これまでは、ピアが既に受信済みであっても、再接続時にcommitment_signedは常に再送されていました。今後は、channel_reestablishに明示的なビットフィールドが含まれ、ノードがまだ必要な場合にのみcommitment_signedを要求できるようになります。これにより不要な再送が回避され、特に将来の Simple Taproot Channelにおいて重要になります。これは再送にはノンスの変更に伴う完全なMuSig2署名ラウンドが必要になるためです。