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

Bitcoin Optech Newsletter #428

Oct 23, 2026

今週のニュースレターでは、発行者の協力なしにユーザーがオンチェーンでビットコインを償還できる単一発行者型のレイヤー2の設計と、アウトプットスクリプトディスクリプターにハッシュのプリイメージを含める提案を掲載しています。また、サービスやクライアントソフトウェアの最近の更新、新しいリリースとリリース候補の発表、人気のあるBitcoin基盤ソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

● 単一発行者型のレイヤー2におけるトラストを最小化した退出: Adam Gibsonは、Lichenの論文と概念実証コードを Bitcoin-Devメーリングリストに投稿しました。Lichenは、 Gibsonがハブと呼ぶ単一の発行者が、シーケンサーと呼ばれるサーバーが運営するレイヤー2の台帳上で、ビットコインと1対1で償還可能なトークンを発行する設計です。各ユーザーはハブとの2-of-2コントラクトを保持しており、ハブが拒否したりオフラインであったりしても、トークンを償還できます。そのため、ユーザーは台帳を正直に運営することについてはシーケンサーを信頼しますが、ビットコインを返還することについてハブを信頼する必要はありません。この設計はLN-GAP（ニュースレター #427参照）をベースにしていますが、その正直な多数派による証明委員会を、完全にオンチェーンで解決される紛争処理に置き換えています。

各ユーザーは、ハブとの自身の2-of-2アウトプットにビットコインをロックし、レイヤー2台帳上で同額のトークンを受け取ります。ユーザー間の支払いはこのレイヤー2台帳上で行われ、チェーンには記録されません。退出する場合、ユーザーはトークンをハブに返し、自身のアウトプットからビットコインを回収します。ユーザーが資金を引き出せるのはこのアウトプットのみであるため、ハブも各アウトプットに（LNのインバウンド流動性と同様に）合意された上限額まで自身のビットコインをロックしておきます。これにより、ユーザーは他のユーザーから受け取ったトークンをビットコインに償還可能になります。上限を超えて受け取ったトークンについては、ハブの裁量でのみ償還可能です。

協調的なケースでは、ハブは単にユーザーに支払うアウトプットの決済に署名します。ハブが拒否したり応答しなかったりした場合、ユーザーは、「シーケンサーがトークンの返却を記録した状態に署名した」ことを示すGroth16証明を生成します。 BitcoinのScriptはこのような証明を検証できないため、ユーザーは代わりに、オンチェーン上で「特定の検証プログラムがその証明を受け入れるはずである」と主張します。これに対してハブが異議を唱えた場合、事前署名されたBitVMXトランザクションによって、争点をScriptで検査可能な単一の実行ステップにまで絞り込みます。双方は紛争に負けた場合に没収される準備金をロックしており、これが虚偽の主張や拒否を抑止します。 Gibsonは、ユーザーへの返却を省略したり、実際には到達していない状態に署名したりするシーケンサーが、依然としてユーザーやハブに資金の損失をもたらす可能性があることを認めており、有効性証明（validity proof）とシーケンサーの委員会を今後の課題として挙げています。
● ハッシュのプリイメージ用のディスクリプター構文: João Diasは、miniscriptにハッシュフラグメント用のプライベートな形式を追加するために BIP379を拡張する提案をDelving Bitcoinに投稿しました。現時点では、使用条件を満たすためにプリイメージを必要とする資金を使用するために、 Bitcoin Coreのウォレットにプリイメージを直接渡す方法はありません。外部ツールを使って、 PSBTのハッシュフィールドのいずれか（例: PSBT_IN_SHA256）で提供することしかできません。著者は、この提案はディスクリプターの作成時にすでに判明しているプリイメージのみを対象としており、 HTLCのように使用時に判明するものは対象としていないと述べました。

Diasは、プリイメージは署名よりも鍵のように扱われるべきであると説明し、ディスクリプターモデルにおける不整合を強調しました。彼のアイデアは、ウォレットがディスクリプターからシークレットをインポートし、トランザクションを直接構築して署名できるようにすることを目指しています。そのために、著者はディスクリプター用の特定の構文（例: sha256(preimage(HEX))）と、一連の制約を提案しました。制約には、素のhex値ではなく特定のマーカーを使用すること、すべてのハッシュフラグメントのサイズを32 byteに固定すること、プリイメージを他のシークレットと同様に扱い、バックアップや暗号化を行い、公開ディスクリプター文字列には決して表示しないことなどが含まれます。

提案の正式化に進む前に、Diasは対処すべき未解決の点をいくつか挙げました。マーカーの構文をどうすべきか、BIP379を修正するか新しいBIPを起草すべきか、 Bitcoin Coreがプリイメージを管理するためのRPCコールを追加する必要があるか、ハードウェア署名デバイスがプリイメージのシークレットを扱うべきか、それともソフトウェアウォレットのみに留めるべきか、鍵マテリアルからプリイメージを決定論的に導出することに関心があるかといった点です。

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

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

● Ibis Wallet v5.0-betaのリリース: Ibis Wallet v5.0-beta（ニュースレター #406参照）は、 BarkをベースにしたArkのサポート、Sparkステートチェーンからの一方的な退出、サイレントペイメントアドレスでの受け取りを追加しています。
● ライトニングによるマイニング報酬支払い用のLandfallウォレット: Landfallは、現在実現可能なUXを示す概念実証ウォレットで、マイニングプールOCEANがLN経由で報酬を支払うために必要とする支払いアドレス、 BOLT12オファー、BIP322署名を Lexeがホストするノード（ニュースレター #419参照）を使用して単一のシードから導出します。なお、本番環境での使用は想定されていません。
● rbitcoin 0.8.0のリリース: rbitcoin 0.8.0は、 Rustで書かれrust-bitcoinをベースに構築されたBitcoinフルノードで、全面的にAIによって書かれたとされています。ウォレットおよびライトニングのバックエンド向けで、UTXOセットをリレーショナルアーカイブに置き換え、 ElectrumおよびEsploraスタイルのAPIを提供し、通信にはBIP324のみを使用します。

リリースとリリース候補

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

● Eclair 0.14.4と0.14.5は、このLNノード実装のセキュリティリリースです。バージョン0.14.4は、ニュースレター #427で説明した、スプライシング、HTLCの決済、オンザフライファンディング、オニオンのパースに関連する複数の問題を修正しています。また、キャッシュされたHTTP Basic認証の認証情報を使ったクロスサイトリクエストフォージェリを防ぐため、 Originヘッダーを持つAPIリクエストを拒否するようになりました（ニュースレター #423参照）。ブラウザベースの統合は、Eclairを呼び出すために独自のバックエンドを使用する必要があります。バージョン0.14.5は、後述するトランポリンルーティングとTaprootスプライシングの脆弱性を修正し、ニュースレター #427で取り上げたオニオンペイロード長の検証に対する整数オーバーフローによるバイパスを塞いでいます。プロジェクトはアップグレードを強く推奨しています。
● BDK chain 0.23.4は、Bitcoinウォレット構築用のBDKライブラリのメンテナンスリリースです。トランザクションの追跡と、過去に使用されたすべてのアドレスを確認し終える前にフルスキャンが停止してしまう問題を修正しています。付随するアップデートでは、再編成後のBitcoin Core RPC同期に関する修正や、以前に取り上げたElectrumの修正（txidの検証、最初のアウトプットがOP_RETURNであるトランザクションの承認検知、再編成後の承認追跡など）を含んでいます。
● LND v0.21.5-beta.rc1とv0.20.6-beta.rc1は、この人気のあるLNノード実装のメンテナンスバージョンのリリース候補です。どちらもニュースレター #418で説明した手数料更新の処理とチャネルメッセージの制限に加え、コミットメントの手数料率の問題、TLVレコードのパース時の過剰なメモリ割り当て、 SQLデータベースのデッドロックの修正を含んでいます。バージョン0.21.5は、ニュースレター #427で説明したTaproot Assetsチャネル向けの補助的なHTLC署名検証の修正も含まれており、ブロックチェーンの再編成中のウォレット同期に関する問題も修正しています。

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

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

● Eclair #3409は、悪意のある支払人がトランポリンペイメントを転送するノードから資金を盗み出せる可能性のある脆弱性を修正しています。Eclairは、送信HTLCが受信HTLCより先に期限切れになることを保証するため、下流ルートの合計CLTV expiry deltaを制限するようになりました（関連する修正についてはニュースレター #423参照）。これまでは、経路探索が失敗した場合、Eclairはルート長と有効期限の制限を緩和して再試行していたため、支払人は過大なexpiry deltaを持つルーティングヒントやブラインドパスを提供することができました。すると支払人は、受信HTLCが期限切れになった後にオンチェーンでそれを取り戻せる一方で、受信者は依然として送信HTLCを請求できる状態になります。Eclairは現在、ルート長の制限のみを緩和し、必要な有効期限の順序を維持します。
● Eclair #3411は、悪意のあるチャネルピアがEclairに無効なスプライシングトランザクションへ署名させることで資金を盗み出せる可能性のある脆弱性を修正しています（関連する修正についてはニュースレター #427参照）。 Simple Taproot Channelをスプライシングする際、ピアは完全なトランザクションの代わりに、インプットの前のアウトプットの金額とスクリプトのみを提供できます。これまでは、Eclairはこれらの値を検証せずに信頼していました。ピアはどちらのフィールドについても嘘をつくことができ、 Taproot署名は使用されるインプットの実際の金額とスクリプトにコミットするため、 Eclairに決して承認されることのないスプライシングトランザクションへ署名させることができました。それにもかかわらず、 Eclairはその無効なスプライシングを最新のチャネルファンディング状態として扱っていました。ピアはその後、以前のファンディングアウトプットを使用する以前に署名済みのコミットメントを公開し、 Eclairの対応する受信HTLCがタイムアウトして返金された後に、送信HTLCをそのペイメントプリイメージを使って請求することができ、 Eclairは転送した支払いを回収できなくなります。Eclairは現在、署名する前に、主張されたアウトプットをBitcoinバックエンドと照合して検証します。
● LDK #5126は、1ホップのブラインドパスを使用するBOLT12支払いが、 HTLCの有効期限が短すぎるという理由で拒否されてしまうバグを修正しています。これまでは、 LDKは導入ノードが受信者でもある場合、パスのcltv_expiry_deltaを無視していました。これは、その値に受信者が要求する最終的なCLTV deltaが含まれているという事実を見落としていました。その結果、支払いはLDKのランダムなCLTVオフセットが十分に大きい場合にのみ受信者の最小要件を満たすという状況が生じていました。これにより、Core Lightningに対するテストにおいて、断続的な支払い失敗が発生していました。LDKは現在、ルートを構築する際と、許容される合計CLTV deltaの最大値を確認する際に、通知されたdeltaを含めます。
● LND #10919は、チャネルジャミング攻撃を緩和するための実験的なローカルレピュテーションシステムを追加しています。これは提案されている HTLCアカウンタビリティスキーム（ニュースレター#377および#387参照）に基づいており、以前のHTLCエンドースメントアプローチを置き換えるものです。このシステムは、過去の転送活動とノードがアドバタイズする手数料に基づいて送信チャネルをスコア付けし、解決に時間がかかりすぎるアカウンタブルなHTLCにペナルティを課します。システムはデフォルトで有効になっており、転送の判断に影響を与えることなく、 HTLCが保護されたリソースの対象となるかどうかをログに記録します。レピュテーションは再起動時にリセットされます。
● BTCPay Server #7679は、ライトニング経由の支払いが重複する可能性があるバグを修正しています。これまでは、支払いが開始され、その後の支払い検索で結果が返されなかった場合、BTCPay Serverは支払いをキャンセルし、保存していたペイメントハッシュを破棄していました。これは支払いが成功していた場合でも発生していました。その結果、オペレーターはすでに成功した支払いに対して別の支払いを発行してしまう可能性がありました。BTCPay Serverは現在、進行中の支払いとそのペイメントハッシュを、後続の確認のために保持します。
● BTCPay Server #7684は、Greenfield APIキーの認可における権限昇格を修正しています。これまでは、特定のストアに制限されたAPIキーが、その限定されたスコープにもかかわらず、サーバー全体またはアカウント全体の権限を行使できました。さらに、他のユーザーのAPIキーを作成する権限を持つキーは、自身よりも広い権限を付与することもできました。BTCPay Serverは現在、リクエストを認可する際に権限スコープを適用し、 APIキーが自身の持たない権限を付与することを防止します。既存の無制限の管理者キーは、意図された機能を維持します。
● BDK #2325と#2360は、ウォレットが要求されたトランザクションデータを取得していないにもかかわらず、同期が成功したと報告する可能性がある2つのバグを修正しています。1つめは、個々のアウトポイントのElectrum同期に影響します。これまでは、 BDKはそれらのトランザクションを取得する際に発生した接続失敗やタイムアウトを含むすべてのエラーを無視していました。これにより、使用済みのアウトプットが未使用として分類されたままになる可能性がありました。BDKは現在、このパスではElectrumプロトコルエラーは無視しつつ、その他の失敗は伝播させます。2つめのPRは、 ElectrumおよびEsploraクライアントのsyncとfull_scanを修正しています。これまでは、 Electrumのbatch_sizeまたはEsploraのparallel_requestsをゼロに設定すると、要求されたスキャンやトランザクションの取得をスキップしながら成功を報告する可能性がありました。両クライアントは現在、これらのパラメータについてゼロを1として扱います。
● BOLTs #1357はBOLT11を更新し、インボイスの読み取り側に対して、ペイメントハッシュ（p）フィールドと支払いシークレット（s）フィールドがそれぞれ1つずつ含まれていない限りインボイスを拒否することを要求します。これまでは、仕様では支払人が最初のpフィールドを使用することを推奨していましたが、一部のインボイスパーサーは最後のものを使用していました。この不一致はLNP2PBotに対して悪用されました。 LNP2PBotのインボイスパーサーとライトニングノードは、異なるペイメントハッシュを選択していました。その結果、ボットは完了した支払いを未払いとして扱い、攻撃者が重複した支払いを得ることを可能にしていました（ニュースレター #425参照）。
● BOLTs #1352は、Simple Taproot Channelの仕様とテストベクトルにおける複数の誤りを修正しています（ニュースレター #404参照）。Taprootのアウトプットキー導出とコントロールブロック構築における誤りは、以前の仕様どおりに実装した場合、無効な支払いを生成する可能性がありました。このPRはまた、 commitment_signedで交換されるHTLC署名がSIGHASH_SINGLE|SIGHASH_ANYONECANPAYを使用することを明確にしています。受信側のピアは、witnessを構築する際に64 byteの署名に0x83を追加します。手数料引き上げのために2段目のトランザクションを結合する際、各HTLCインプットとそれに対応するアウトプットは、結合後のトランザクションで同じインデックス位置にある必要があります。その他の修正は、アンカーの使用パス、MuSig2のnonceのエンコーディングと導出、ローカルおよびリモートのコミットメントテストベクトルに関するものです。これらの変更は、プロトコルの動作を変更することなく、仕様を既存のLNDおよびEclairの実装と整合させるものです。