今週のニュースレターは、COLDCARD署名デバイスで生成されたウォレットに影響する深刻な脆弱性について警告し、 Core Lightningにおける2つのサービス拒否脆弱性の開示と、ゼロ知識証明を用いたProof of Reserveの概念実証について掲載しています。 また、Bitcoin Stack Exchangeから厳選されたQ&A、新しいリリースとリリース候補の発表、 人気のBitcoin基盤ソフトウェアの注目すべき更新など恒例のセクションも含まれています。

アクションアイテム

  • ● COLDCARDで生成された鍵で管理されている資金の移動: COLDCARD Mk3を使用してウォレットを生成した場合、 そのウォレットで受け取ったすべての資金は盗難のリスクにさらされています。 そのため、影響を受けていないウォレットへ慎重かつ速やかに移動させるべきです。 他のCOLDCARDモデルで生成されたウォレットも影響を受けている可能性があります。 詳細は以下のニュースセクションを参照してください。

ニュース

  • ● COLDCARDで生成されたウォレットに盗難のリスク: 2026年7月30日、一部のビットコインユーザーが、自身のCOLDCARDウォレットから7月29日に一連の予期せぬトランザクションを通じて資金が盗まれていることに気付きました。 同日中に、COLDCARD Mk3のファームウェアにバグがあり、それにより不十分なエントロピーでウォレットが生成されてしまうことが判明しました。 本記事執筆時点で、推定被害額は1,000BTCを超えており、事態の進展に伴いこの数字はさらに増加する可能性があります。

    Coinkiteによるセキュリティ勧告では、ファームウェアの バージョン4.0.1（2021年3月）以降（最新版を含む）を使用してCOLDCARD Mk3で生成されたウォレットが、 盗難に対して脆弱であると指摘されました。ただし、十分な外部エントロピー（50回以上のサイコロを振るなど）を用いてシードが作成されていた場合や、 強力なパスフレーズが追加設定されていた場合は例外です。 この勧告では、バージョン5.6.0未満のMk4およびMk5ファームウェア、ならびにバージョン1.5.0Q未満のQファームウェアで生成されたシードも、 影響を受けるとされています。

    Coinkiteはその後の技術解説の中で、このバグの原因を、 2021年のコード変更により、シード生成がデバイスのハードウェアRNGではなく、 予測可能なデバイス固有値で初期化されるソフトウェアPRNGへ意図せずルーティングされてしまったことにあると説明しています。 追加のサイコロ操作による補足なしに影響を受けたMk3で生成されたシードは、本来意図された128bitではなく、実質的に約40bitのエントロピーしか持ちません。 影響を受けたMk4、Mk5、Qデバイスから生成されたシードは、セキュアエレメントの出力もミックスされているため攻撃はより困難ですが、 Coinkiteとの連携のもと匿名の研究者と共に実施され開示されたBlockによる分析では、 そのエントロピーのうちPRNG状態に反映されるのはわずか32bitに過ぎず、これらのシードも意図されたセキュリティレベルには依然として大きく届かないことが判明しました。

    複数の開発者が最先端のAIモデルの支援を受けて、この攻撃を即座に再現することに成功したため、この脆弱性は現在悪用が進行中であると想定すべきです。 Blockの分析では、4.xファームウェアを実行している古いCOLDCARD Mk2もMk3と同程度に影響を受けていることが追加で特定されており、 ペーパーウォレットの秘密鍵やエフェメラルシードなど、他のランダム生成された秘密情報も影響を受けることが指摘されています。

    事態は依然として進行中であり、このニュースレターの公開後にもさらなる情報が明らかになる可能性が高いです。 読者はCoinkiteのブログをはじめとする情報源で最新情報を確認してください。 Bitcoin Optechは、影響を受ける可能性のあるCOLDCARDユーザーに対し、 影響を受けていないウォレットへ慎重かつ速やかに資金を移動させるよう推奨しています。 追加のサイコロ操作による補足なしに影響を受けたデバイスで生成されたシードは、侵害されたものとして扱うべきです。 Mk4、Mk5、Qデバイスのユーザーは、新しいウォレットを生成する前に、修正されたファームウェアにアップグレードしてください。 アップグレードするだけでは既存のシードは安全になりません。

  • ● Core Lightningの2つのDoS脆弱性の開示: Chandra Pratapは、Summer of Bitcoinプログラムのインターンシップ中に Core Lightningで発見した2つのサービス拒否（DoS）脆弱性についてDelving Bitcoinに投稿しました。 具体的には、これらの脆弱性により、攻撃者はノードのメモリを枯渇させてノードをクラッシュさせることが可能でした。 このバグはgossipdデーモンのステートマシン、特にconnectdデーモンとのインターフェイスに関連するものです。 Pratapは、2つのモジュール間の通信の堅牢性をテストすることを目的とした新しいファズターゲット fuzz-gossipd-connectdに取り組んだことで、これらの脆弱性を発見することができました。

    1つめの脆弱性は、2つのデーモン間で共有されるデーモン間メッセージキューに関連するもので、 このキューの目的はネットワークから届くすべてのchannel_updateメッセージを保存することです。 攻撃者はノードをメッセージで溢れさせることで、内部キューを際限なく増大させ、 利用可能なすべてのRAMを消費させることが可能でした。 このバグは、Core Lightning #8376で、キューがメッセージをドロップできるようにし、 50万メッセージという上限（カットオフポイント）を設けるというシンプルな方法で修正されました。

    2つめの脆弱性は、1つめの脆弱性を修正しようとした際に発見されました。 具体的には、欠落している可能性のあるチャネルについてピアに問い合わせるために、 未知のショートチャネルID（SCID）を追跡するのに使用される内部マップに関連するものでした。 攻撃者は偽のSCIDでノードを溢れさせることで、メモリ消費を増大させ続けることが可能でした。 このバグ自体はそれまで報告されていなかったものの、Rusty RussellによってCore Lightning #8903で既にパッチの作業が進められており、 そこでは内部マップの改良されたガベージコレクションメカニズムが導入されました。

  • ● ゼロ知識Proof of Reserveの概念実証: fabohaxは、Bitcoin向けの 非カストディアルなProof of Reserveシステムの概念実証である zkPoH（”zero-knowledge proof-of-hodl”）について投稿しました。 このプロトタイプでは、ユーザーは合計金額が1億sats（1BTC）以上のUTXOのセットを自身が保持していることを、 それ以上の情報を一切明らかにすることなく証明できます。

    この概念実証は、オフチェーンで生成されたUTXOのスナップショットを入力として受け取り、 それをマークルツリーにコミットし、そのルートが公開コミットメントになります。 証明者はスナップショットから最大4つのUTXOを選択し、Noir回路用のウィットネス入力を生成します。 この回路は、選択されたUTXOが実際にスナップショットに属していること、マークルパスが有効であること、 選択されたUTXOの合計が少なくとも要求された金額であることを検証します。検証者が知ることができるのは、 証明者が1億sats（1BTC）の要件を満たしているということだけです。

    本記事執筆時点では、この概念実証に明示的な所有権の紐付けを行う手順は組み込まれていません。つまり、 選択されたUTXOが実際に証明者に属していることを証明する方法はありません。 著者は現在、回路外での所有権チェック、あるいは回路内に直接組み込む形のいずれかで、 この機能の追加に取り組んでいます。プロトタイプは現在、専用のリポジトリで公開されています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • ● BTCPay Server 2.4.1は、このセルフホスト型ペイメントプロセッサのメンテナンスリリースです。 BIP329ウォレットラベルのインポート（ニュースレター #415参照）や、 インボイスの編集可能なコメント機能、その他いくつかの改善とバグ修正が追加されています。

  • ● Eclair 0.14.1は、このLNノード実装のメンテナンスリリースです。 Bitcoin Core 31.xが必要になったほか、マルチパスペイメントで正しく動作しなかった実験的な BOLT12のブラインドパス手数料割引を無効化し、いくつかのバグ修正とパフォーマンス改善が含まれています。 カスタムのオファーハンドラープラグインを使用しているオペレーターは、リリースノートを確認してください。

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

最近の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 #34628は、ピアごとに独立していたトランザクションリレーのバックログを、 個数およびシリアライズ後のサイズに基づくトークンバケットで制御される、 グローバルなインバウンド/アウトバウンドバックログに置き換えます。これにより、 ピア間での重複した保存とソートが削減されます。これらはCPU枯渇問題の一因となっていました（ニュースレター #324 参照）。インバウンドピアのバックログにおけるリレークレジットは、 初期値として420トランザクショントークンおよび12MBが割り当てられ、 毎秒14トランザクションと20kBのレートで補充されます。個数の上限は420トークンですが、 サイズの蓄積上限は50MBとなっています。アウトバウンドの補充レートについては、 ニュースレター #373で説明された2.5倍の係数が維持されます。 リレー需要が利用可能なクレジットを超えた場合、トランザクション間の依存関係を尊重しつつ、 マイニングスコアに基づいて優先順位が決定されます。選択されたトランザクションは、その後、 小規模なランダム化されたピアごとのキューに投入されます。 新しいgetnetworkinfoフィールドは各バックログとそのトークン残高を公開し、 デバッグ専用の-txsendrateオプションで異なる個数レートをテストできます。

  • ● Bitcoin Core #28463は、デフォルトの最大接続数を125から200に引き上げるとともに、 -inboundrelaypercentオプション（デフォルト値50）を追加します。このオプションは、 トランザクションをリレーするピアが占有できるインバウンドスロットの最大割合を設定するものです。 デフォルトで11個のアウトバウンドスロットが確保されるため、インバウンド接続には189個のスロットが残り、 デフォルト設定ではそのうち最大94個をトランザクションをリレーするピアが占有できます。この制限は、 ピアが自身のリレーの設定を通知した後に適用され、ピアが後からBIP37メッセージを使用して トランザクションリレーを有効にした場合には再チェックされます。これにより、 低帯域幅でのブロックリレー用のキャパシティが確保され、エクリプス攻撃への耐性を向上させるための、 より多くのアウトバウンドのブロックリレー専用接続の追加に備えます。

  • ● Bitcoin Core #32800は、いくつかのRPCに明示的なBIP141および ポリシー調整済みトランザクションサイズのフィールドを追加しました。 vsize_bip141はトランザクションのウェイトから計算された仮想サイズを報告し、 vsize_adjustedはその値と設定された-bytespersigopポリシーの下で トランザクションのsigopsコストから導かれるサイズのうち、大きい方を報告します。 調整済みの値は、mempoolポリシーおよびブロックテンプレートの手数料率計算に使用されます。 getmempoolentry、verboseモードのgetrawmempool、testmempoolaccept、submitpackageは、 両方のフィールドを報告するようになりました。既存のvsizeフィールドは、 BIP141の仮想サイズとして文書化されていましたが、実際にはポリシー調整済みの値を含んでいたため、 維持されるものの非推奨としてマークされます。さらに、getrawtransactionは トランザクションがmempoolにある場合にvsize_adjustedを報告し、 既存のvsizeはBIP141の値のままです。getorphantxsのverbose出力にも明示的な vsize_bip141フィールドが追加されます。

  • ● Bitcoin Core #34683は、RPCインターフェースのOpenRPC 1.4.1記述を自動生成します。 新しいrpc.discoverRPCは公開インターフェースを返し、getopenrpcinfo はオプションで隠しコマンドと引数を含めることができます。このドキュメントは、 登録されたすべてのRPCのRPCHelpManメタデータから実行時に生成され、メソッドのパラメータ、 必須値とデフォルト値、結果の形式、その他のインターフェースの詳細を記述します。

  • ● Bitcoin Core #33014は、ファイナライズ済みのスクリプトフィールドに値が入力されているものの、 無効な署名を含むPSBTをdescriptorprocesspsbt（ニュースレター #253参照）が 処理する方法を修正します。これまでは、このRPCは最終スクリプトの存在のみをチェックして、 PSBTを完了とマークし、トランザクションの抽出が失敗した場合は内部エラーを返していました。 現在は、完了を報告する前にすべてのインプットを検証するため、無効な署名を持つPSBTは、 hexフィールドにシリアライズされたトランザクションを含めずにcomplete: falseを返します。

  • ● Eclair #3325は、reply_pathを含むBOLT12インボイスのオニオンメッセージを受け入れます。 受取人は、支払人がインボイスを無効と判断した場合にinvoice_errorを返せるように、 ブラインドされた返信パスをインボイスに添付できます。 Eclairはこれまでこの組み合わせを拒否していたため、インボイスに返信パスを追加したLDK （ニュースレター #321参照）との相互運用性の問題を引き起こしていました。

  • ● BOLTs #1346は、BOLT12のPayer Proof（支払人証明）、つまり 支払人がペイメントプリイメージ、インボイスを発行したノードの署名、invreq_payer_idによる支払人の署名を使用して （プライバシーのため一部のインボイスフィールドを省略可能にし） 支払人がインボイスを支払ったことを証明するレシートフォーマットを規定します。 この仕様では人が読みやすいプレフィックスlnpが割り当てられ、 生成と検証のテストベクターが追加されています。Core Lightningは初期のドラフトを実験的に実装していました（ニュースレター #405参照）。

  • ● BOLTs #1344は、失敗の帰属プロトコルを成功したペイメントにも拡張し、 ペイメントプリイメージを返してHTLCを決済するメッセージであるupdate_fulfill_htlcに オプションのfulfillment_payloadを追加します。パディングフィールドのみが定義されているため、 このPRは、署名付きkeysendレシートなど、 将来の成功関連データのためのトランスポートを確立するもので、まだ何らかのアプリケーションを標準化するものではありません。

  • ● BOLTs #1343は、チャネルピアからのオニオンメッセージのみを受け入れるノード向けの option_onion_messages_only_channels機能ビットを追加します。この機能を通知しないノードは、 チャネルを持たないピアからのオニオンメッセージを受け入れるべきですが、レート制限やドロップは引き続き行ってもかまいません。 この機能により、送信者は失敗することが分かっているリレーパスを回避でき、 同時にオペレーターはサービス拒否攻撃へのエクスポージャーを減らすことができます。 チャネルを持たないピアからのオニオンメッセージを受信するものの転送しないLNDの動作に対処する LDKの回避策については、ニュースレター #409を参照してください。

もっと知りたいですか？

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