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

Bitcoin Optech Newsletter #373

Sep 26, 2025

今週のニュースレターでは、Eclairの旧バージョンに影響を与える脆弱性と、フルノードの手数料率設定に関する調査結果に関するまとめを掲載しています。また、Bitcoin Stack Exchangeで人気の質問とその回答や、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

● Eclairの脆弱性: Matt Morehouseは、Eclairの旧バージョンに影響する脆弱性の責任ある開示をDelving Bitcoinで発表しました。すべてのEclairユーザーは、バージョン0.12以降へのアップグレードが推奨されます。この脆弱性により、攻撃者は古いコミットメントトランザクションをブロードキャストすることで、チャネルから現在の資金をすべて盗むことができました。この脆弱性の修正に加えて、 Eclairの開発者は、同様の問題を検出するための包括的なテストスイートを追加しました。
● 手数料率設定の調査: Daniela Brozzoniは、着信接続を受け付けている約3万台のフルノードをスキャンした結果を Delving Bitcoinに投稿しました。各ノードに対して、 BIP133のfeefilterをクエリし、リレーされる未承認トランザクションを受け入れる現在の最低手数料率を取得します。ノードのmempoolがいっぱいになっていない場合、これはノードのデフォルト最小トランザクションリレー手数料率です。彼女の調査結果によると、ほとんどのノードは、Bitcoin Coreで長年デフォルトとなっている 1 sat/vbyte (s/v)というデフォルト値を使っていました。約4%のノードが、 Bitcoin Coreの次期バージョン30.0のデフォルト値である0.1 s/vを使っていました。また、約8%のノードはクエリに応答しませんでした。これらは、スパイノードである可能性があります。

少数のノードが9,170,997（10,000 s/v）という、feefilter値を使用していましたが、開発者の0xB10Cによると、これはノードがチェーンの先端から100ブロック以上遅れており、後のブロックで承認される可能性のあるトランザクションよりも、ブロックデータの受信にフォーカスしている場合に、 Bitcoin Coreの内部処理によって設定される値です。

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

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

● Bitcoin Coreバージョン30.0におけるOP_RETURNの変更の影響は？ Pieter Wuilleは、マイニングされるブロックの内容に影響を与えるために mempoolとリレーポリシーを使用することの有効性と欠点について、彼の見解を説明しています。
● OP_RETURNリレー制限が効果的でないなら、なぜデフォルトの抑止策として残すのではなく、安全策を削除するのでしょうか？ Antoine Poinsotは、Bitcoin Coreにおける現在のOP_RETURNのデフォルト制限値によって生じる悪影響と、それを削除した理由について説明しています。
● Bitcoin Core v30でOP_RETURNの上限が設定されていない場合、最悪のストレスシナリオとはどのようなものですか？ Vojtěch StrnadとPieter Wuilleは、OP_RETURN制限ポリシーのデフォルト設定の変更によって発生する可能性のある一連の極端なシナリオを回答しています。
● OP_RETURNがより多くの容量を必要とするなら、なぜ80 byteの上限を160 byteに引き上げるのではなく削除したのですか？ Ava ChowとAntoine Poinsotは、OP_RETURNのデフォルト値を160 byteにした場合の考慮事項を概説しています。具体的には、上限を継続的に設定し続けることへの抵抗、既に上限を回避している大規模マイナーの存在、将来のオンチェーン活動を予測できないリスクなどが含まれます。
● 任意のデータが避けられないなら、OP_RETURN制限の削除は需要をより有害な保存方法（UTXOを膨張させるアドレスなど）にシフトさせるのでは？ Ava Chowは、OP_RETURN制限を撤廃することで、特定の状況において、アウトプットデータの保存により害の少ない代替手段を使用するインセンティブを与えると指摘しています。
● OP_RETURNの上限解除によってUTXOセットが増加しない場合、ブロックチェーンの肥大化と中央集権化の圧力にどのような影響を与えますか？ Ava Chowは、OP_RETURNの使用の増加がBitcoinノードのリソース利用にどのように影響するかを説明しています。
● OP_RETURNの上限解除は、長期的な手数料市場の品質とセキュリティ予算にどのような影響を与えますか？ Ava Chowは、OP_RETURNの仮定的な使用と将来のBitcoinマイニング収益への影響について、一連の質問に回答しています。
● 100KBのOP_RETURNでブロックチェーンが違法コンテンツに悩まされないという保証はありますか？ユーザーjb55は、データのエンコード方式の例をいくつか挙げ、「つまり、検閲耐性のある分散型ネットワークでは、一般的にこのような行為を実際に阻止することはできない」と結論づけています。
● OP_RETURNの上限撤廃がブロックの伝播やオーファンリスクに悪影響を与えないことを示す分析はありますか？ Ava Chowは、大きなOP_RETURNを具体的に分離したデータセットは存在しないものの、コンパクトブロックとステイルブロックに関する過去の分析では、それらが異なる動作をすると予想する理由はないと指摘しています。
● Bitcoin Coreは、ブロックデータファイルとLevelDBインデックスの両方のXOR難読化鍵をどこに保管していますか？ Vojtěch Strnadは、chainstateの鍵はLevelDB内の”\000obfuscate_key”キーの下に保管され、ブロックとundoデータの鍵は、blocks/xor.datファイルに保管されていると述べています。
● Bitcoin Core 28.0における1P1Cトランザクションリレーはどの程度堅牢ですか？ Glozowは、オリジナルの楽観的な1P1C（one parent one child）リレーのプルリクエストで言及されている非堅牢性は、「特に敵対者が存在する場合や、トランザクション量が非常に多いために見逃してしまうような場合には、動作が保証されない」という意味だと明確に述べています。
● getblocktemplateで1 sat/vbyte未満のトランザクションを含めるためにはどうすればいいですか？ユーザーinershaは、1 sat/vbyte未満のトランザクションをリレーするだけでなく、候補ブロックテンプレートに含めるために必要な設定を発見しました。

リリースとリリース候補

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

● Bitcoin Core 30.0rc1は、この完全な検証ノードソフトウェアの次期メジャーバージョンのリリース候補です。バージョン30リリース候補のテストガイドをご覧ください。

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

最近の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 #33333は、ノードのdbcache設定がノードのシステムRAMから算出された上限を超えた場合、メモリ不足エラーや過剰なスワップを防止するために、起動時に警告メッセージを出力します。 RAMが2GB未満のシステムの場合、dbcache警告の閾値は450MBです。それ以外の場合、閾値はRAMの総容量の75%です。dbcacheの16GB制限は、2024年9月に撤廃されました（ニュースレター#321参照）。
● Bitcoin Core #28592は、ネットワーク上で小さなトランザクションが増加したことに伴い、インバウンドピアのピア毎のトランザクションリレーレートを7から14に増やしました。アウトバウンドピアのレートは、2.5倍の1秒あたり35トランザクションになりました。トランザクションリレーのレート制限は、ノードがピアに送信するトランザクション数を制限します。
● Eclair #3171は、チャネル残高の均一性を前提とする経路探索手法であるPaymentWeightRatiosを削除し、過去の支払いの試行履歴に基づく新たに導入した確率的アプローチ（ニュースレター#371参照）に置き換えます。
● Eclair #3175は、offer_chains、offer_paths、invoice_pathsおよび invoice_blindedpayの各フィールドが存在するものの空の場合、支払い不可能なBOLT12 オファーを拒否するようになりました。
● LDK #4064は、署名検証ロジックを更新し、nフィールド（受取人の公開鍵）が存在する場合は、署名がそのフィールドに対して検証されるようにします。そうでない場合は、受取人の公開鍵は、high-Sまたはlow-S署名を持つBOLT11インボイスから抽出されます。このPRは、署名チェックをBOLTs #1284やEclair（ニュースレター#371参照）などの他の実装と合わせます。
● LDK #4067は、手数料ゼロのコミットメントトランザクションの P2Aエフェメラルアンカーアウトプットの使用をサポートし、チャネルピアがオンチェーンで資金の返還を請求できるようにします。ゼロ手数料コミットメントチャネルのLDKの実装については、ニュースレター#371をご覧ください。
● LDK #4046は、頻繁にオフラインになる送信者が、頻繁にオフラインになる受信者に非同期支払いを送信できるようにします。送信者は、受信者がオンラインに戻り、支払いを請求するためのrelease_held_htlc オニオンメッセージを送信するまで、 LSPがHTLCを保持することを示すフラグをupdate_add_htlcメッセージにセットします。
● LDK #4083は、重複するBIP353 HRN支払いAPIを削除するため、 pay_for_offer_from_human_readable_nameを非推奨にします。ウォレットは、BIP353 HRN（例：satoshi@nakamoto.com）からのオファーに支払うために、pay_for_offer_from_hrnを呼び出す前に、 bitcoin-payment-instructionsクレートを使用して支払い指示をパースし解決することが推奨されます。
● LND #10189は、sweeperシステムを更新し（ニュースレター#346参照）、 ErrMinRelayFeeNotMetエラーコードを正しく認識し、ブロードキャストが成功するまで手数料を引き上げることで、ブロードキャストに失敗したトランザクションを再試行します。これまでは、エラーが一致せず、トランザクションは再試行されませんでした。このPRには、LNDのTaproot Assetsを強化するために使用される Taprootオーバーレイチャネルに関連する、追加のお釣りアウトプットを考慮することで、ウェイトの推定も改善します。
● BIPs #1963は、コンパクトブロックフィルターを定義する BIP（BIP157およびBIP158）のステータスを、DraftからFinalに更新します。これは2020年以降、Bitcoin Coreおよびその他のソフトウェアで展開されたことを受けたものです。