今週のニュースレターでは、Stratum v2プールマイナーがシェアに変換した ブロックテンプレートに含まれるトランザクション手数料の補償を受け取れるようにする提案と、 提案中のOP_CAT opcodeを調査する研究基金の発表、 ソフトフォークの有無にかかわらずマークルツリーの脆弱性を緩和する議論を掲載しています。 また、新しいリリースやリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● 手数料収益の分配のためのStratum v2拡張: Filippo Merliは、 シェアに個々のマイナーが選択したトランザクションが含まれている場合に、 シェアに含まれる手数料の金額を追跡できるようにするStratum v2の拡張について、 Delving Bitcoinに投稿しました。これを使用すると、 プールからマイナーに支払われる金額を調整することができ、手数料率の高いトランザクションを選択したマイナーには、 より多くの金額が支払われます。

    Merliは、選択したトランザクションに基づいて異なるマイナーに異なる金額を支払う際の課題のいくつかを検証した、 共同執筆した論文のリンクを貼っています。この論文では、 PPLNS（ pay per last N shares ）プールマイニング支払いスキームと互換性のあるスキームが提案されています。 彼の投稿には、このスキームの2つの進行中の実装へのリンクがあります。

  • ● OP_CAT研究基金: Victor Kolobovは、 OP_CAT opcodeを追加するソフトフォーク案の研究に100万ドルの基金を設ける発表を Bitcoin-Devメーリングリストに投稿しました。 「関心のあるトピックとしては、BitcoinでOP_CATを有効にした場合のセキュリティへの影響、 BitcoinでのOP_CATベースのコンピューティングとロックスクリプトのロジック、 BitcoinでOP_CATを利用するアプリケーションとプロトコル、 OP_CATとその影響に関する一般的な研究が含まれますが、これらに限定はされません。」 提出は2025年の1月1日までです。

  • ● マークルツリーの脆弱性の緩和: Eric Voskuilは、 コンセンサスクリーンアップのソフトフォーク提案に関するDelving Bitcoinの議論のスレッドに（ ニュースレター #296参照）、Bitcoin-Devメーリングリストでの 最近の議論を踏まえた更新の要望を投稿しました。 特に彼は、「64 byteのトランザクションの無効化の提案には正当性がない」と考えています。 これは、コンセンサスの変更なしで実行できる他のチェック（実際、それらのチェックは現在実行されています）と比較して、 64 byteのトランザクションを禁止することで CVE-2012-2459のようなマークルツリーの脆弱性から保護するフルノードのパフォーマンスは向上しないという 彼の主張に基づいたものです。コンセンサスクリーンアップ提案の推進者であるAntoine Poinsotは、 このフルノードの側面については同意しているようでした： 「 64 byteのトランザクションを無効にすることで、より早い段階でブロック障害をキャッシュすることができるという 私が最初に述べたことは誤りです。」

    しかし、Poinsotらは以前、CVE-2017-12842に対してマークルプルーフを検証するソフトウェアを保護するために、 64 byteのトランザクションを禁止する提案をしていました。この脆弱性は、 元のBitcoinの論文に掲載されているように、 SPV（ simplified payment verification ）を使用する軽量ウォレットに影響します。 また、SPVを実行するサイドチェーンにも影響し、 ソフトフォークによるアクティベーションを必要とするコベナンツにも影響する可能性があります。

    CVE-2017-12842の公開以来、ブロック内のコインベーストランザクションの深さをさらにチェックすることで、 SPVを安全にできることが分かっています。Voskuilは、一般的な最近のブロックで平均576 byteの追加が必要になると推定しています。 これは帯域幅のわずかな増加です。Poinsotは、議論を要約し、 Anthony Townsは追加で深さの検証を実行する複雑さに関する議論を展開しました。

    Voskuilはまた、ブロックヘッダーをマークルツリーの深さにコミットする代替ソフトフォークによるコンセンサスの変更に関する Sergio Demian Lernerの以前の提案のリンクも掲載しています。 これにより、64 byteのトランザクションを禁止することなく、CVE-2017-12842から保護され、 SPVのプルーフが最大限効率的になります。

    この記事の執筆時点では議論は進行中でした。

リリースとリリース候補

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

  • ● Core Lightning 24.08は、この人気のLNノード実装のメジャーリリースで、 新しい機能とバグ修正が含まれています。

  • ● LDK 0.0.124は、LN対応アプリケーションを構築するこのライブラリの最新リリースです。

  • ● LND v0.18.3-beta.rc2は、この人気のLNノード実装の軽微なバグ修正リリースのリリース候補です。

  • ● BDK 1.0.0-beta.2は、ウォレットやその他のBitcoin対応アプリケーションを構築するためのこのライブラリのリリース候補です。 元のbdk Rustクレートの名前がbdk_wallet変更され、 低レイヤーのモジュールは、 bdk_chain、bdk_electrum、bdk_esplora、bdk_bitcoind_rpcなどの独自のクレートに抽出されました。 bdk_walletクレートは、「安定した 1.0.0 API を提供する最初のバージョンです」。

  • ● Bitcoin Core 28.0rc1は、主要なフルノード実装の次期メジャーバージョンのリリース候補です。 テストガイドが利用可能です。

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

最近の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へのコミットは、master開発ブランチに適用されるため、 これらの変更がリリースされるのは、次期バージョン28のリリースから約6ヶ月後になると思われます。

  • ● Bitcoin Core #30454と#30664は、 それぞれCMakeベースのビルドシステム（ニュースレター #316参照）を追加し、 autotoolsベースのビルドシステムを削除します。後続のPR#30779、 #30785、#30763、 #30777、#30752、 #30753、#30754、 #30749、#30653、 #30739、#30740、 #30744、#30734、 #30738、#30731、 #30508、#30729、 #30712もご覧ください。

  • ● Bitcoin Core #22838は、複数の導出パスディスクリプター（BIP389）を実装しました。 これにより、1つのディスクリプター文字列で2つの関連する導出パスを指定できます。1つめは支払いの受け取り用、 2つめは内部用（お釣りなど）です。ニュースレター#211および#258をご覧ください。

  • ● Eclair #2865では、切断されたモバイルピアの最後の既知のIPアドレスへの接続を試み、 モバイル通知をプッシュすることで、そのモバイルピアをウェイクアップする機能が追加されました。 これは、ローカルノードが支払いやOnionメッセージを保持し、 ピアがオンラインに戻るとそれが配信されるような非同期支払いの文脈で特に有用です。 ニュースレター#232をご覧ください。

  • ● LND #9009は、無効なチャネルアナウンス（既に使用されたチャネルや、ファンディングトランザクションがないチャネル、 ファンディングアウトプットが無効）を送信するピアを禁止する仕組みを導入しました。禁止ピアは、 関係に応じて異なる方法で処理されます:

    • 共有チャネルのない禁止ピアの場合、ノードはそれらのピアを切断します。

    • 共有チャネルを持つ禁止ピアの場合、ノードは48時間そのピアのチャネルアナウンスをすべて無視します。

  • ● LDK #3268は、突然の手数料の急上昇による不要な強制閉鎖を回避するために、 相手方の手数料率を確認する際のdust計算用の より保守的な手数料推定法であるConfirmationTarget::MaximumFeeEstimateを追加します。 このPRはまた、ConfirmationTarget::OnChainSweepをUrgentOnChainSweepと NonUrgentOnChainSweepに分割し、時間に敏感な強制閉鎖（HTLCの期限切れなど）と 緊急性のない強制閉鎖を区別します。

  • ● HWI #742は、Trezor Safe 5ハードウェア署名デバイスのサポートを追加します。

  • ● BIPs #1657は、BIP353を使用する場合のDNSSEC証明用に PSBTアウトプットに新しい標準フィールドを追加します。ハードウェア署名者などの外部デバイスは、 PSBTアウトプットを調べて、RFC 9102形式の証明を取得することができます。 これにより、有効な証明のみが受け入れられるように時間的制約が適用されます。 ニュースレター#307をご覧ください。