今週のニュースレターでは、Bitcoin Coreの旧バージョンに影響のある脆弱性の今後の開示の発表と、 testnetの新バージョンのBIPドラフト、関数型暗号に基づくコベナンツの提案、 Bitcoin Scriptで64 bit演算を実行するための提案のアップデート、 OP_CAT opcodeを用いてsignet上のProof of Workを検証するためのスクリプトのリンク、 BIP21仕様bitcoin: URIの更新案を掲載しています。 また、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● Bitcoin Coreの旧バージョンに影響する脆弱性の今後の開示: Bitcoin Coreプロジェクトのメンバー数名が、旧バージョンのBitcoin Coreに影響を与える脆弱性の開示方針案について、 IRC上で議論しました。深刻度の低い脆弱性については、 脆弱性を解消する（または十分に緩和する）Bitcoin Coreのバージョンが最初にリリースされてから約二週間後に詳細を開示します。 その他のほとんどの脆弱性については、脆弱性の影響を受けるBitcoin Coreの最後のバージョンが End-of-Life（リリースから約1年半後）に達した後で詳細が開示されます。まれな重大な脆弱性については、 Bitcoin Coreのセキュリティチームのメンバーが最も適切な開示のタイムラインについて非公開で議論します。

    この方針についてさらに議論する機会を得た後、Bitcoin Core 24.*以下に影響する脆弱性の開示を始めることがプロジェクトの意図です。 すべてのユーザーと管理者は、今後二週間以内にBitcoin Core 25.0以上にアップグレードすることを強く推奨します。 可能な場合は常に最新バージョン（執筆時点では27.0）、または特定のリリースシリーズの最新バージョン（例： 25.xリリースシリーズの場合は25.2、26.xリリースシリーズの場合は26.1）を使用するのが理想的です。

    これまでと同様に、Optechは監視しているインフラプロジェクト（ Bitcoin Coreを含む）に影響する すべての重要なセキュリティの開示の要約を提供します。

  • ● testnet4のBIPと実験的な実装: Fabian Jahrは、 既存のtestnet3のいくつかの問題（ニュースレター #297参照）を解消するために設計された testnetの新バージョンであるtestnet4のBIPドラフトの発表を Bitcoin-Devメーリングリストに投稿しました。 Jahrはまた、提案された実装のBitcoin Coreのプルリクエストのリンクも掲載しています。 testnet4にはtestnet3との顕著な違いが2つあります:

    • ● 難易度-1への戻りが少ない: （偶然であれ故意であれ）最後から2番めのブロックから20分以上後のタイムスタンプを持つ最後のブロックをマイニングすることで、 2016ブロックの全期間を最小難易度（難易度-1）に減らすことは簡単でした。 現在、期間の難易度は、mainnetで使用される通常の方法でのみ下方調整できますが、 タイムスタンプが前のブロックから20分以上経過している場合、新しい期間の最初のブロックを除く すべての個々のブロックを難易度-1でマイニングすることは可能です。1

    • ● タイムワープの修正: testnet3（およびmainnet）では、タイムワープ攻撃を悪用することで難易度を上げることなく、 10分毎に1回よりも大幅に高速にブロックを生成することができました。 testnet4では、mainnetのコンセンサスクリーンアップ ソフトフォークの一部として提案されたタイムワープのソリューションが実装さています。

    BIPのドラフトでは、testnet4について議論されたものの使用されなかった追加の代替案もいくつか言及されています。

  • ● 関数型暗号のコベナンツ: Jeremy Rubinは、 理論的には関数型暗号を利用することで、コンセンサスを変更することなく、 Bitcoinにあらゆるコベナンツの振る舞いを追加することができるという論文を Delving Bitcoinに投稿しました。基本的にこれは、 コベナンツのユーザーが第三者をトラストする必要があるものですが、 そのトラストは複数の当事者に分散され、特定の時点でその内の1人だけが正直に行動すればよいものです。

    要するに、関数型暗号により、特定のプログラムに対応する公開鍵を作成できます。 プログラムを満たすことができる当事者は、（対応する秘密鍵について知る必要なく）公開鍵に対応する署名を作成することができます。

    Rubinは、これは既存のコベナンツの提案よりも、（結果の署名検証を除く）すべての操作がオフチェーンで行われ、 （公開鍵と署名を除く）データをオンチェーンで公開する必要がないという点で優れていると指摘しています。 これにより、常によりプライベートになり、多くの場合スペースを節約できます。複数の署名チェックを実行することで、 同じスクリプトで複数のコベナンツプログラムを使用することができます。

    Trusted Setupの必要性に加えて、Rubinは関数型暗号のもう1つの欠点として、 「暗号技術が未発達なため、現時点で使用するのは現実的ではない」と述べています。

  • ● 64 bit演算のソフトフォーク提案のアップデート: Chris Stewartは、Bitcoin Scriptで64 bit整数を扱う機能を追加するという以前の提案（ ニュースレター#285および#290参照）のアップデートを Delving Bitcoinに投稿しました。 主な変更点は:

    • ● 既存のopcodeの更新: OP_ADD64のような新しいopcodeを追加する代わりに、 既存のopcode（OP_ADDなど）を64 bitで動作するよう更新しています。 大きな数値のエンコードは、現在の小さな数値に使用されているエンコードとは異なるため、 大きな数値を使用するようアップグレードされたスクリプトの断片は、修正が必要になる場合があります。 Stewartは、OP_CHECKLOCKTIMEVERIFYが5バイトのパラメーターではなく8バイトのパラメーターを取る必要がある例を挙げています。

    • ● 結果にbool値が含まれる: 演算が成功すると、 結果がスタックに置かれるだけでなく、演算が成功したことを示すbool値もスタックに置かれます。 演算が失敗する一般的な理由の1つは、結果が64 bitよりも大きく、フィールドサイズがオーバーフローする場合です。 コードでは、演算が正常に完了したことを保証するためにOP_VERIFYを使用できます。

    Anthony Townsは、スクリプトで演算が成功したかをさらに検証するのではなく、 オーバーフローが発生した場合に、デフォルトのopcodeが失敗するという代替アプローチの主張を返信しました。 演算によってオーバーフローが発生するかどうかをテストすることが有用な場合は、 ADD_OFなどの新しいopcodeが利用できるようにします。

  • ● Proof of Workを検証するOP_CATスクリプト: Anthony Townsは、 OP_CATを使用して、スクリプトに送られたコインをProof of Work（PoW）を使用して 誰でも使用できるようにするsignet用のスクリプトについてDelving Bitcoinに投稿しました。 これは分散型のsignet-bitcoinのFaucetとして使用することができます。 マイナーまたはユーザーが余剰のビットコインを持っている場合、彼らはそれをスクリプトに送金します。 ユーザーはsignet bitcoinが必要になると、スクリプトへの支払いをしているUTXOを検索し、 PoWを行い、コインを要求するためにそのPoWを使用するトランザクションを作成します。

    Townsの投稿では、スクリプトといくつかの設計上の選択の動機を掲載しています。

  • ● BIP21更新の提案: Matt Coralloは、 BIP21bitcoin: URIの仕様の更新について、Bitcoin-Devメーリングリストに投稿しました。 以前説明したように（ニュースレター #292参照）、ほぼすべてのBitcoinウォレットは、 指定されたものとは異なるURIスキームを使用しており、インボイスプロトコルへの追加の変更は、 BIP21の使用における追加の変更に繋がる可能性があります。提案の主な変更点は次のとおりです:

    • ● base58check以外: BIP21では、 すべてのBitcoinアドレスがbase58checkエンコーディングを使用することが想定されていますが、 これはP2PKHやP2SHアウトプットのレガシーアドレスのみに使用されます。 最近のアウトプットはbech32やbech32mを使用しています。 今後の支払いにおいては、サイレントペイメントアドレスや LNオファープロトコルで受信されることもありますが、 これらはほぼ確実にBIP21ペイロードとして使用されます。

    • ● 空のボディ: 現在BIP21では、 ペイロードのボディ部にBitcoinアドレスを指定する必要があり、 クエリパラメーターは追加の情報（支払額など）を指定します。 BIP70ペイメントプロトコルなどの以前のペイメントプロトコルでは、 使用する新しいクエリパラメーターが定義されていました（BIP72参照）が、 パラメーターを理解していないクライアントでは、ボディ部のアドレスを使用することになります。 場合によっては、受信者は（サイレントペイメントなどプライバシーを重視するユーザーなど）、 基本アドレスタイプ（base58check、bech32、bech32m）にフォールバックしたくない場合があります。 提案されている更新では、ボディフィールドを空にすることができます。

    • ● 新しいクエリパラメーター: この更新では、 BOLT11インボイスのlightning（現在使用中）、 LNオファーのlno（提案中）、サイレントペイメント用のsp（提案中）という3つの新しいキーを掲載しています。 また、将来のパラメーター用のキーの命名方法についても説明しています。

    Coralloは投稿の中で、ウォレットは正常に解析できないbitcoin: URIを無視または拒否するため、 この変更はすべての既知の展開済みソフトウェアに対して安全であると述べています。

リリースとリリース候補

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

  • ● Core Lightning 24.05rc2は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。

  • ● Bitcoin Core 27.1rc1は、この主要なフルノード実装のメンテナンスバージョンのリリース候補です。

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

今週の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の注目すべき変更点。

  • ● Core Lightning #7252は、lightningdの動作を変更し、 協調チャネルクローズ中にignore_fee_limitsの設定を無視します。 これにより、相手がLDKノードである場合に、 Core Lightning (CLN)チャネル開設ノードが手数料を過剰に支払う問題が修正されます。 このシナリオでは、開設ノードではないLDK（アリス）が協調チャネルクローズを開始し、 手数料の交渉を始めると、開設ノードであるCLN（ボブ）はignore_fee_limits設定により、 手数料をmin_satsからmax_channel_sizeまでの範囲で設定できると応答します。 LDKは（BOLTの仕様に反して）「常に最高許容額を選択」します。 そのためボブは上限を選択し、アリスがそれを受け入れるため、アリスは手数料を大幅に過払いしたトランザクションをブロードキャストします。

  • ● LDK #2931は、経路探索中のログの記録を強化し、直接つながっているチャネルに関する追加データ（ 欠落の有無、最小HTLC金額、最大HTLC金額など）を含めるようにしました。 ログの追加は、各チャネルの利用可能な流動性と制限を可視化することで、 ルーティングの問題をより適切にトラブルシューティングすることを目的としています。

  • ● Rust Bitcoin #2644は、bitcoin_hashesコンポーネントにHKDF (HMAC (Hash-based Message Authentication Code) Extract-and-Expand Key Derivation Function)を追加し、 Rust BitcoinでBIP324を実装します。HKDKは、キーマテリアルのソースから安全かつ標準化された方法で暗号鍵を導出するために使用されます。 （v2 P2Pトランスポートとして知られている）BIP324は、 （Bitcoin Coreでデフォルトで有効になっている）暗号化接続を介して、Bitcoinノードが相互に通信できるようにする方法です。

  • ● BIPs #1541は、標準トランザクションのサブセットであるTRUC（ Topologically Restricted Until Confirmation）トランザクション（v3トランザクション）の仕様BIP431を追加します。 これはトランザクションPinning攻撃を克服するためのコストを最小限に抑えつつ、 トランザクションの置換を可能にするよう設計された追加ルールを備えています。

  • ● BIPs #1556は、圧縮トランザクション の仕様BIP337を追加します。 これはBitcoinトランザクションを圧縮し、サイズを最大50%削減するシリアライゼーションプロトコルです。 これらは、衛星やアマチュア無線、ステガノグラフィーなどの低帯域幅での送信に実用的です。 compressrawtransactionとdecompressrawtransactionという2つのRPCコマンドが提案されています。 BIP337の詳細な説明については、ニュースレター#267をご覧ください。

  • ● BLIPs #32は、提案中のDNSベースの人が読めるBitcoin支払い指示（ニュースレター #290参照）を Onionメッセージで使用し、 bob@example.comのようなアドレスに支払いを送信できるようにする方法について記載したBLIP32を追加しています。 たとえば、アリスはボブに支払いをするよう彼女のLNクライアントに指示します。 彼女のクライアントはDNSアドレスを安全に直接解決できないかもしれませんが、 Onionメッセージを使用して、DNS解決サービスを通知しているピアの一つにコンタクトできます。 そのピアは、example.comのbobエントリーのDNS TXTレコードを検索し、 その結果をDNSSEC署名と一緒にアリスへのOnionメッセージの応答に入れます。 アリスはその情報を検証し、それを使ってオファープロトコルでボブにインボイスを要求します。

脚注

この段落は公開後に編集されました。訂正してくださったMark “Murch” Erhardtに感謝します。

  1. ↩