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

Bitcoin Optech Newsletter #421

Sep 4, 2026

今週のニュースレターでは、マイニングプールがコインベーストランザクションでサイレントペイメントを使ってマイナーに支払いをするアイデアと、古いバージョンのCore Lightningに影響するDoS（サービス拒否）脆弱性の責任ある開示を掲載しています。また、Bitcoinのコンセンサスルールの変更に関する提案や議論のまとめや、新しいリリースとリリース候補の発表、人気のあるBitcoin基盤ソフトウェアへの注目すべき更新など恒例のセクションも含まれています。

ニュース

● コインベーストランザクションでのマイナーへの支払いにサイレントペイメントを利用する: average_garyは、マイニングプールがコインベーストランザクション内で直接マイナーごとに異なるアドレスへ支払う方法についてのアイデアをDelving Bitcoinに投稿しました。プールにxpubを渡して支払いごとに新しいアドレスを導出させる方式では、プールのデータベースが侵害された場合にプライバシー上の問題が生じる可能性があります。その代わりに、マイナーはStratum v2が提供する暗号化された通信チャネルを通じて、静的で何度使ってもプライバシーが漏洩しないサイレントペイメントアドレスを共有できます。

BIP352のサイレントペイメントでは、受信者がトランザクションのインプットに含まれる公開鍵から共有シークレットを導出しますが、コインベーストランザクションにはそれがありません。そこでプールは、送信側の公開鍵A_sendを導出するために使う一時的な秘密鍵を作成します。プールが悪意ある秘密鍵a_sendを探索（グラインド）するのを防ぐため、 A_sendを現在マイニング中のブロックの高さとともにハッシュします。これが通常のトランザクションにおけるOutPoint由来の一意性の代わりとなります。最終的に34 byteのA_sendは、いわゆるプールタグの代わりにコインベースのscriptSigに格納され、マイナーはブロックチェーンをスキャンして資金を見つけられるようになります。

著者は、このアイデアを正式な仕様へと発展させるため、フィードバックや批評を求めています。
● CLNにおけるDoS脆弱性の責任ある開示: Erick Cestariは、25.09より前のバージョンのCLNノードに影響を及ぼす重大なサービス拒否（DoS）脆弱性に関する情報を、責任ある開示の手順に従ってDelving Bitcoinに投稿しました。攻撃者は、チャネルを開設することなくBOLT8のハンドシェイクを完了させるだけで、ノードに対して可能な限り大きいpong応答を要求するpingメッセージを大量に送りつけ、 TCPソケットを一切読み取らないことで、ノードをメモリ不足（OOM）によるクラッシュに追い込むことが可能でした。

この問題はCLNの接続管理方法に関係していました。各ピアはノードとBOLT8の暗号化されたNoiseチャネルを開き、その接続はconnectdという専用のデーモンによって管理されます。このデーモンはTCP接続を処理し、受信メッセージを復号し、送信元ピアとのペイメントチャネルを管理する特定のサブデーモンへルーティングします。しかし、一部のメッセージはデーモン自身がローカルで処理します。その1つがpingメッセージであり、送信者はpong応答のサイズを指定できます。

CLNはサブデーモンへルーティングされるメッセージにはバックプレッシャー（負荷制御）の仕組みを適用しており、 connectdはサブデーモンの準備が整うまで待ってから新しいメッセージを読みます。しかし、デーモン自身が処理するメッセージにはこれが適用されず、ローカル処理されるメッセージは読み続けていました。攻撃者は、許容される最大サイズである65,531 byteの応答を要求するpingメッセージを繰り返し送信し、応答を一切読まないことで、まず自分のTCPソケットバッファを、次にピア側のバッファを埋め尽くせました。これによりpeer_outqキューが排出されなくなり、OOMクラッシュが発生する事態となっていました。

この問題は、connectdデーモンに独自のバックプレッシャーの仕組みを設け、次の受信メッセージを読む前に実際にpeer_outqキューが排出されることを条件とすることで修正されました。修正はCore Lightning #8525で導入され、リリース25.09で公開されました。

コンセンサスの変更

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

● PQCアウトプットタイプに関する議論の続き: 先月取り上げたポスト量子アウトプットタイプに関する Pieter WuilleのDelving Bitcoinスレッドのまとめに続き、 Wuilleは、CISAとP2TRv2を組み合わせれば移行への強いインセンティブになるという Conduitionの主張に返信しました。Wuilleは、手数料率の節約（多くのインプットを持つトランザクションにおいて最大約28%のウェイト削減と試算）だけでは、いわゆるロングテール層（多数の小規模なウォレットやカストディアンなど）を動かすには不十分だと考えています。その理由として、ウォレットやカストディアンのサポートがボトルネックであること、CISAは仕様と実装の複雑さを増してP2TRv2ソフトフォークを遅らせる可能性があること、事業者がP2TRv2とCISAを同時にリリースできるようになるまでPQC関連の作業を先延ばしにする可能性があることを挙げています。彼は依然として、一般的なユーザー向けのデフォルトとしてP2TRv2を、 EC上の点（公開鍵）を隠したい高度なユーザー向けにはP2MRをデフォルトとすることを好ましいと考えています。耐量子時代においては、ハッシュベース署名に対して、シリアライズ後のサイズよりも CPU負荷を重視する新たなウィットネスのコスト計算ルールが必要になるだろうと指摘しました（ニュースレター #417参照）。また、第三者のリレーノードが署名を逐次的に集約する方式は、実際の帯域幅コストをコンセンサス層の内側に隠してしまい、マイナーへの直接送信を促すことで既存のマイニングプールを既得権益化しかねないと警告しました。Conduitionは、 CISAをサポートするアウトプットタイプをまず通常のBIP340署名で採用し、署名の集約機能は後から追加することも可能だと反論しました。また、ハッシュベース署名の手数料をEC署名と競合できるレベルにするために（シリアライズ後の）ブロックサイズを8倍（あるいはそれ以上）に拡大する場合、ブロック全体のSNARK集約でウィットネスを削減（プルーニング）できなければ、アーカイブストレージは年間テラバイト規模になると述べました。 Adam Gibsonは、CISAをP2TRv2に束ねることはP2TRv2の「まず普及を」という目標に適さないというWuilleの見解に同意しました。
● DropKick: commit/reveal方式のPQC救済策: Conduitionは、 Bitcoin-DevメーリングリストにDropKickの概要を投稿しました。これは、 Q-day（耐量子計算機耐性が必要になる日）までにコインをPQC対応のアウトプットに移動させていないユーザー向けの、 commit/reveal方式のポスト量子救済プロトコルです（ニュースレター #361および #348参照）。ユーザーは、自身のポスト量子公開鍵と所有権の証明（知識の非対称性を示す証拠）へのコミットメントを、ブロック内のどこか（例えばOP_RETURNやtaproot tweakなど）に隠します。PQ耐性のあるUTXOを自分で持たないユーザーは、信頼できないアグリゲーターにコミットメントを渡すことができます。アグリゲーターは多数のユーザーのコミットメントを単一のオンチェーンルートの下にマークルコミットメントとしてまとめます（その際、救済されるコインから手数料を支払うことも可能です）。一定期間の遅延の後、ユーザーは証明（ポスト量子公開鍵による署名）と、そのコミットメントが以前のブロックに含まれていたことを示すSPV方式の開示証明を提示します。 DropKickは、知識の非対称性が判定可能なUTXO（ハッシュされた公開鍵などの隠れたデータが存在することを、検証者がアウトプットだけから判断できるもの）のみを対象とする限り、没収を伴わないソフトフォークとして展開できます。 BIP32の鍵導出のような判定不能なケースまで対象にすればより多くのコインを救えますが、一部のコインが没収されるリスクも生じます。なお、P2PKのコインは対象にできません。コミットメントを投稿するために各ユーザーがPQセキュアなUTXOを持つ必要があるTadge DryjaのLifeboatと比べると、 DropKickはオンチェーンの全コミットメントをインデックス化し順序付ける必要をなくしますが、その代償としてreveal時のマイナーによる検閲リスクがあります。Conduitionは、長めの遅延（ユーザーがUTXOの1%を正直なマイナーに支払うなら約100ブロック）と金額に比例した手数料を組み合わせれば検閲を不採算にできると主張しています。ただしこれは、検閲者が検閲の試みを覆すブロックを再編成する能力を持たない、あるいはその意思がないことを前提としています。
● SHRINCSのBIPドラフト: ConduitionはSHRINCSワーキンググループを代表してBitcoin-Devメーリングリストに、 Bitcoin向けの半ステートフルなハッシュベース署名方式としてSHRINCSを規定する最初のドラフトを投稿しました（ニュースレター #391参照）。公開鍵は48 byteです。ステートフルな署名は最小で548 byte、組み込みのステートレスなフォールバックは5,777 byteの署名を生成します（ドラフトでは、LNのような高頻度プロトコルでもフォールバックを利用できるよう、ステートレス署名の許容回数上限を2^40回に引き上げています）。検証速度は、 SHA256のハードウェアアクセラレーションを利用する場合、バイトあたりBIP340のSchnorr署名の4〜16倍高速で、最悪の場合でもステートレス署名1つあたりSHA256圧縮処理2,792回分です。当初の提案からの主な変更点には、 SLH-DSA（FIPS-205）とのブラックボックス互換性、任意の構造を取れる柔軟なXMSSツリー、そしてより高速（かつサイズの大きい）ステートフルパラメーターの採用が含まれます。ドラフトが規定するのは署名方式のみで、新しいopcodeや新しいアウトプットタイプによるこの新署名のデプロイは別途の提案の対象となります。ステートフルなカウンタを再利用すると、観測者に署名を偽造されてしまいます。Antoine Riardは、 5,777 byteのステートレス署名は、これらのフィールドが割引されない限り現在のトランザクションのおよそ90倍のオンチェーンコストになると指摘しました。また、マシン検証されたWOTS+C証明を伴うJonas Nickとremix7531のCライブラリlibshrincsも、 SHRINCSを統合したい人々への実装面の支援として別途リリースされました。
● BIP448およびCSFS/CTVのデモとアプリケーション: BIP448（OP_TEMPLATEHASH、OP_CHECKSIGFROMSTACK（CSFS）、 OP_INTERNALKEYをまとめたTapscriptバンドル。ニュースレター #397参照）に関する取り組みが続いており、デモや実装、概念実証を集約する新しいサイトが登場しています。BIP448のGitHub Organizationでは Bitcoin Inquisition（アクティベーションを伴わないBitcoin Coreパッチ）、miniscriptとPSBTの統合、 LN-SymmetryのBOLTドラフトとCore Lightningでの実装、 ArkのOP_TEMPLATEHASHのsignet上でのデモといった実装が収集されています。同Organizationによると、次回のBitcoin Inquisitionリリースでは、デフォルトsignet上でこのバンドル一式が利用可能になる予定です。 askii21mはTaprootアウトプットを構築し、選択可能なopcodeセットの下で Tapscriptをステップ実行できるブラウザベースのエディターであるcovenants.diyを発表しました。このエディターには、BIP448の再バインド可能な状態、BIP119のVaultと輻輳制御、 BIP348の委任などの例がパーマリンク付きで掲載されています。CofundのJesus Najera（setzeus）は、 Vault、輻輳制御、Arkの発行、LN-Symmetryなど20以上の構成を含むインタラクティブな Covenants Use-Case Atlasを公開しました。

Ademanは、小規模なジャストインタイム（JIT）ライトニングチャネルを開くために使われるArkの OOR（Out-Of-Round）仮想トランザクションアウトプット（VTXO）割り当てに関連する構成案を投稿しました。 Arkサーバーはオペレーターであると同時に最初のVTXO保有者でもあるため、現状では同じVTXOを何度も再割り当てすることが可能です。 Ademanの二重解釈防止用ボンド（equivocation bond）は、割り当て用の鍵を用いて、異なるBIP341 sighashに対する2つのCSFS検証可能な署名を公開することで没収の対象となります。このボンドと事前割り当てされたトランザクションツリーには次トランザクションへのコベナンツが必要で、それにはOP_CHECKTEMPLATEVERIFY（CTV）またはOP_TEMPLATEHASHのいずれかを利用できます。

リリースとリリース候補

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

● Core Lightning 26.06.7は、人気のあるLNノード実装の現行メジャーバージョンに対するセキュリティリリースです。責任ある開示が行われた複数の脆弱性を修正しており、いずれも実際に悪用されていることは確認されていません。これらの脆弱性は、上記のニュースセクションで開示について説明したErick Cestariを含む研究者らによって報告されました。プロジェクトは全ユーザーに強くアップグレードを推奨しています。ニュースレター #420で述べたとおり、修正内容のリバースエンジニアリングを遅らせるため、ソースコードは8月28日のバイナリリリースから14日間公開が保留されます。その後、 CLNの再現可能なビルドによってユーザーはバイナリを検証できるようになります。 8月28日から9月1日の間にv26.06.7またはlatestタグをプルしたDockerユーザーは、新バージョンを名乗るものの修正を含まないイメージを受け取っています。該当するユーザーはイメージのダイジェストを確認し、再度プルする必要があります。
● LND v0.21.3-betaは、人気のあるLNノード実装のメンテナンスリリースです。後述の注目すべきコード更新セクションで説明するピアのリソース制限、channel_updateのエンコーディング修正、ダストHTLCの解決の修正に加え、ニュースレター #420のPSBT資金供給デッドロック修正を含みます。また、Taproot Assetsチャネルのような補助アウトプットを持つチャネルにおける協調閉鎖手数料のバグ、レガシーなAMPインボイスに対するネイティブSQLインボイスマイグレーションの失敗、 REST WebSocketプロキシのパニック、いくつかのゴシップクエリと協調閉鎖のバグを修正し、実験的なXCreateAccount RPCを追加しています（ニュースレター #419参照）。
● LND v0.20.4-betaは、LNDの0.20リリースブランチのメンテナンスリリースです。ピアのリソース制限、channel_updateのエンコーディング修正、ダストHTLCの解決修正を含む0.21.3-betaの修正の大半をバックポートしており、さらにインバウンド手数料やMuSig2のnonceのような固定長TLVレコードについて、宣言された長さが誤っている場合に黙って受理・再エンコードするのではなく拒否するようになりました。

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

最近の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 #36111は、validateaddress RPCにおいて、長過ぎるbech32文字列に対するエラーを報告する際に使用されるメモリを制限します。これまでは、BIP173が定める90文字の制限を超える文字列に対して、制限を超えた各位置すべてがエラー位置として返され（ニュースレター #177参照）、それぞれが個別のJSON値に変換されていました。今後、RPCは長さ違反が始まる90文字目のみを返します。作者のテストでは、HTTPリクエストの最大サイズに近い認証済みリクエストで、変更前は約5.7 GiBのメモリを消費していましたが、変更後は240 MiBとなりました。
● Bitcoin Core #36032は、createrawtransaction、createpsbt、sendmanyなど、トランザクションを構築するRPCのパフォーマンスを改善します。具体的には、アウトプットのパースを二次関数的処理から線形処理に変更しました。これまでのパーサーは、アウトプットのキーを反復処理する度に、対応する値をそれぞれ個別に検索していたため、その都度同じ内部リストを走査し直していました。加えて、sendmanyはパース中もウォレットのロックを保持していました。今後、パーサーはニュースレター #419のgettxspendingprevout修正と同様に、インデックスに基づいてキーと値を一緒に走査するようになります。作者の報告では、デバッグビルドで10,000個のアウトプットをパースする時間が1.8秒から0.5秒に短縮されました。
● Core Lightning #9435は、BOLT2の規定に従い、ピアからnext_commitment_numberがゼロのchannel_reestablishメッセージが送信された場合にチャネルを強制閉鎖するようCLNを更新します。ゼロという値はピアがチャネルの状態を失ったことを示しており、最新のコミットメントトランザクションをブロードキャストすることで、ピアはStatic Channel Backupを用いて残高を回復できます。これまでは、 CLNはこれを開いたばかりのチャネルに対してのみ強制していました。それ以外のチャネルでは、 CLNはまずピアの古いnext_revocation_numberを検出して警告を送り、チャネルは開いたままにしていました。
● Eclair #3368は、非Taprootチャネルのピアから受け取ったcommitment_signedメッセージに、 Simple Taproot ChannelがMuSig2の部分署名に使う partial_signature_with_nonce TLVを含んでいる場合のバグを修正します（ニュースレター #404参照）。 Eclairはメッセージの通常のECDSA署名を正しく検証していたものの、意図せず送信された部分署名をピアの署名として誤って保存していました。これにより、Eclairが後でチャネルを強制閉鎖できなくなっていました。今後、 Eclairは検証前にチャネルのコミットメント形式に合致する署名タイプを選択し、検証済みの署名のみを保存します。
● Eclair #3366は、仕様に準拠しないピアに対するスプライシングの安全性を強化します。 Eclairは、自身のstfu静止メッセージの後にチャネル更新を送るピアや、スプライシングの交渉中にcommitment_signedメッセージを送るピアを切断するようになりました。スプライシングの署名中にピアがチャネルの既存コミットメントを進めようとした場合は、受理する代わりに強制閉鎖します。また、コミットメント番号がチャネルのものと一致しなくなったスプライシングやデュアルファンディングのRBFの試行も拒否します。さらに、 EclairがLiquidity Adsを通じて流動性を販売するスプライシングが署名開始後に中断された場合、 Eclairはその対価となる受信HTLCを直ちに失敗させるようになりました（関連する修正についてはニュースレター #379参照）。
● LND #11090は、受信pingメッセージにレート制限をかけ、各ピアの送信メッセージキューに上限を設けることで、上記ニュースセクションでCLNについて述べたようなリソース枯渇を防ぎます。各ピア接続について、 LNDは2つのトークンバケットを保持するようになりました。受信pingリクエスト用のバケットは200トークンから始まり、毎秒10トークンずつ補充されます。このバケットを使い切ったピアは切断されます。送信pong応答用のバケットは20トークンから始まり、毎秒1トークンずつ補充されます。こちらを使い切るとLNDは応答を停止します。これはBOLT1からの意図的な変更です。各ピアの送信キューにも10,000メッセージまたは約16 MiBの上限が設けられます。さらにこのPRは、 channel_updateゴシップメッセージのエンコーディングを修正し、インバウンド手数料を広告するLND自身の更新が、ブロードキャストするバイト列とまったく同じものに対して署名されるようにします。これまではこれらのバイト列が異なることがあり、ピアが更新を拒否する原因となっていました。また、 LNDが他ノードから転送する更新についても、認識できないTLVレコードを削除して発信元の署名を無効にするのではなく、そのまま保持するようになりました（同様のEclairの修正についてはニュースレター #418参照）。
● LND #11140は、送信側チャネルが強制閉鎖され、転送中のHTLCが一方の当事者のコミットメントトランザクションでのみダストとしてトリムされる場合のLNDの処理方法を修正します。これまでは、HTLCがLND側のコミットメントにはアウトプットを持つがピア側のコミットメントがアウトプットなしで承認された場合、 LNDは自分のコミットメントを基準に判断していたため、受信HTLCをフェイルバックしませんでした。その結果、受信HTLCは上流のチャネルが期限近くで強制閉鎖されるまで保留のままとなっていました。今後、LNDは実際に承認されたコミットメントに基づいて判断します。また、送信HTLCが自分のコミットメントではダストだがピアのコミットメントでアウトプットを持つ場合、ピアがプリイメージでそのアウトプットを請求できる可能性があるため、LNDは受信HTLCを早期に失敗させなくなりました。
● HWI #792では、signtxコマンドに--registrationオプションが追加されました。このオプションを使用すると、 registerdescriptorコマンドでハードウェア署名デバイスに登録されたBIP388ウォレットポリシーを使ってPSBTに署名できます（ニュースレター#419および#420参照）。このオプションは、 registerdescriptorが返すシリアライズされた登録情報（ポリシー名、ディスクリプター、デバイスタイプ、LedgerのHMACのようなデバイス固有の登録データ）を受け入れます。 BitBox02、Coldcard Edge、Jade、および非レガシーなLedgerデバイスがサポートされています。
● BDK #2262は、ウォレットのトランザクショングラフを再インデックスする際に、ウォレット自身のアウトプットの一部を見落とす可能性があったバグを修正します。BDKのKeychainTxOutIndexは、これまでに見た最大のBIP32導出インデックスを超えて先読みするアドレスのウィンドウを監視し、より大きいインデックスのアウトプットが見つかるたびにウィンドウを拡張します。これまでは、再インデックスは各アウトプットを一度しか調べなかったため、現在のウィンドウを超えるアウトプットはウォレットに属さないと判断され、後のアウトプットによってウィンドウが拡張された後も再検査されることはありませんでした。アウトプットはランダムな順序で調べられるため、同じウォレットでも実行ごとに異なる残高が表示されることがありました。再インデックスは今後、ウィンドウの拡張が止まるまで処理を繰り返します。

もっと知りたいですか？

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