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

Bitcoin Optech Newsletter #358

Jun 13, 2025

今週のニュースレターでは、セルフィッシュマイニングの危険閾値の計算方法や、高手数料率のトランザクションのフィルタリングの防止に関するアイディアのまとめ、 BIP390musig()ディスクリプターの変更案に関するフィードバックの募集、ディスクリプター暗号化用の新しいライブラリの発表を掲載しています。また、 Bitcoin Core PR Review Clubの概要や、新しいリリースとリリース候補の発表、そして人気のBitcoinインフラストラクチャプロジェクトの最近の更新など、恒例のセクションも含まれています。

ニュース

● セルフィッシュマイニングの危険閾値の計算: Antoine Poinsotは、セルフィッシュマイニング攻撃の名称の由来となった 2013年の論文の数式（ただし、この攻撃自体は2010年に既に説明されていました）を拡張した記事をDelving Bitcoinに投稿しました。彼はまた、この攻撃を実験するための簡略化されたマイニングおよびブロックリレーシミュレーターも提供しています。彼は、2013年の論文の結論の1つを再現することに焦点を当てています。それは、ネットワーク全体のハッシュレートの33%を制御する不正なマイナー（または強力な繋がりがあるマイナーのカルテル）は、その他の追加の優位性がなくても、ハッシュレートの67%を制御するマイナーよりも、長期的にわずかながら利益を上げることができるというものです。これは33%のマイナーが、発見した新しいブロックの一部のアナウンスを選択的に遅らせることで実現されます。不正なマイナーのハッシュレートが33%を超えると、その収益性はさらに高まり、最終的には50%のハッシュレートを超えて、競合他社がベストブロックチェーン上に新しいブロックを保持できないようにすることができます。

Poinsotの投稿を詳しくレビューしたわけではありませんが、彼のアプローチは妥当であるように思われ、数学的な検証や理解を深めたいと考えている方には、ぜひお勧めします。
● 上位のmempoolのセット調整によるリレーの検閲耐性: Peter Toddは、高手数料率のトランザクションをフィルタリングしているピアをノードが切断できるようにするメカニズムについてBitcoin-Devメーリングリストに投稿しました。このメカニズムは、クラスターmempoolと、 erlayで使用されているようなセット調整メカニズムに依存します。ノードは、クラスターmempoolを使って、（たとえば）8,000,000 weight単位（最大8MB）に収まる、最も収益性の高い未承認トランザクションのセットを計算します。ノードの各ピアも、未承認トランザクションの上位8 MWUを計算します。 minisketchなどの効率的なアルゴリズムを使って、ノードはピアとトランザクションのセットを調整します。これにより、各ピアのmempoolの上位にどのようなトランザクションがあるかを正確に学習します。その後、ノードは平均して収益性の低いmempoolを持つピアとの接続を定期的に切断します。

収益性の低い接続を切断することで、ノードは最終的に、高手数料率のトランザクションをフィルタリングする可能性が最も低いピアを見つけることができるでしょう。 Toddは、クラスターmempoolのサポートがBitcoin Coreにマージされた後で実装に取り組みたいと述べました。彼はこのアイディアはGregory Maxwellらの功績だと述べており、 Optechは基本的なアイディアについてニュースレター #9で初めて言及しました。
● musig()式で参加者の鍵の重複を許可するようBIP390を更新: Ava Chowは、アウトプットスクリプトディスクリプター内の musig()式で同じ参加者の公開鍵を複数使用できるようにBIP390を更新することに反対する人がいるかどうかを Bitcoin-Devメーリングリストで尋ねました。これは、実装を簡素化し、MuSig2の仕様であるBIP327では明示的に許可されています。この記事の執筆時点では反対意見はなく、ChowはBIP390の仕様を変更するプルリクエストを公開しました。
● ディスクリプター暗号化ライブラリ: Josh Domanは、アウトプットスクリプトディスクリプターまたは miniscriptの機密部分を、そこに含まれる公開鍵で暗号化するライブラリを作成したことを Delving Bitcoinで発表しました。彼は、復号に必要な情報について説明しています:
- 使用する際にウォレットが2-of-3の鍵を求める場合、復号にも正確に2-of-3の鍵が必要になります。
- ウォレットが「2つの鍵 OR タイムロックと別の鍵」のような複雑なminiscriptポリシーを使用している場合は、すべてのタイムロックやハッシュロックが満たされているかのように、暗号化も同じ構造に従います。
これは、ニュースレター #351で説明した暗号化ディスクリプターバックアップ方式とは異なります。その方式では、ディスクリプター内に含まれる任意の公開鍵の知識があれば、ディスクリプターを復号できます。 Domanは、この方式は、暗号化ディスクリプターがブロックチェーンなどの公開または半公開のソースにバックアップされている場合に、より優れたプライバシーを提供すると主張しています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、重要な質問と回答のいくつかに焦点を当てます。以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Separate UTXO set access from validation functionsは、 TheCharlatanによるPRで、UTXOセット全体を要求するのではなく、必要なUTXOのみを渡すことで検証関数を呼び出せるようにします。これは、bitcoinkernelプロジェクトの一部で、 Utreexoノードや SwiftSyncノード（ニュースレター #349参照）など、 UTXOセットを実装していないフルノード実装において、ライブラリをより使いやすくするための重要なステップです。

最初の4つのコミットでは、このPRにより、検証関数がUTXOセットに直接アクセスするのではなく、呼び出し側が必要なCoinまたはCTxOutをまず取得し、それらを検証関数に渡すことで、トランザクション検証関数とUTXOセット間の結合を低減します。

それ以降のコミットでは、UTXOセットとのやりとりを必要とする残りのロジックを別のSpendBlock()メソッドに分離することで、ConnectBlock()のUTXOセットへの依存を完全に解消します。

このPRで、ConnectBlock()関数から新しいSpendBlock()関数を切り離すことがなぜ役立つのですか？ 2つの関数の目的をどのように比較しますか？

ConnectBlock()関数は、もともとブロックの検証とUTXOセットの変更の両方を実行していました。このリファクタリングにより、これらの役割が分割されます。ConnectBlock()関数は、 UTXOセットを必要としない検証ロジックのみを担当し、新しいSpendBlock()関数は UTXOセットとのすべてのやりとりを処理します。これにより、呼び出し元は、 ConnectBlock()を使ってUTXOセットなしでブロックの検証を行えます。 ➚
UTXOセットなしでカーネルを使用できるようになること以外に、この分離に別の利点はありますか？

UTXOセットの無いプロジェクトでカーネルを使用できるようになることに加えて、この分離により、コードを個別にテストしやすくなり、保守も容易になります。あるレビュアーは、UTXOセットへのアクセスが不要になることで、 SwiftSyncの重要な機能であるブロックの並列検証が可能になると指摘しています。 ➚
SpendBlock()は、CBlock blockおよびCBlockIndex pindex、 uint256 block_hashパラメーターを受け取ります。これらはすべて使用されるブロックを参照します。なぜ3つのパラメーターが必要なのでしょうか？

検証コードはパフォーマンスが重要であり、ブロックの伝播速度などの重要なパラメーターに影響します。 CBlockやCBlockIndexからブロックハッシュを計算すると、値がキャッシュされないためコストがかかります。そのため、作者はパフォーマンスを優先し、計算済みのblock_hashを別のパラメーターとして渡すことにしました。同様に、pindexをブロックインデックスから取得することもできますが、これは厳密には必要のない追加のマップ検索を必要とします。
注: 作者は後にアプローチを変更し、 block_hashのパフォーマンス最適化を削除しました。 ➚
このPRの最初のコミットでは、CCoinsViewCacheをいくつかの検証関数の関数シグネチャからリファクタリングしています。 CCoinsViewCacheはUTXOセット全体を保持しているのでしょうか？なぜそれが問題になるのか（あるいは問題にならないのか）？このPRは、その動作を変更しますか？

CCoinsViewCacheはUTXOセット全体を保持するわけではありません。これは、UTXOセット全体をディスクに保存するCCoinsViewDBの前に位置するメモリ内のキャッシュです。要求されたコインがキャッシュにない場合は、ディスクから取得する必要があります。このPRは、キャッシュの動作自体を変更するものではありません。関数シグネチャから CCoinsViewCacheを削除することで、UTXOセットへの依存関係を明示し、呼び出し元は検証関数を呼び出す前にコインを取得する必要があります。 ➚

リリースとリリース候補

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

● Core Lightning 25.05rc1は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。
● LND 0.19.1-betaは、この人気のLNノード実装のメンテナンスバージョンのリリースです。複数のバグ修正が含まれています。

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

最近の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 #32406は、デフォルトの-datacarriersizeの設定を83から 100,000 byte（トランザクションの最大サイズ制限）に引き上げることで、 OP_RETURNアウトプットのサイズ制限（標準ルール）の上限を解除します。 -datacarrierおよび-datacarriersizeオプションは引き続き使用できますが、非推奨としてマークされており、将来のリリース（未定）で削除される可能性があります。さらに、このPRにより、OP_RETURNアウトプットはトランザクションに付き1つというポリシー制限も解除され、サイズ制限はトランザクション内のすべてのアウトプットに割り当てられるようになりました。この変更に関する詳細は、ニュースレター #352をご覧ください。
● LDK #3793は、ピアに次のn個(batch_size)のメッセージを単一の論理単位として扱うように指示する新しいstart_batchメッセージを追加します。また、PeerManagerを更新し、スプライシング中のcommitment_signedメッセージについて、バッチ内の各メッセージにTLVとbatch_sizeフィールドを追加するのではなく、このメッセージに依存するようにしています。これは、LN仕様で定義されている唯一のバッチ処理であるcommitment_signedメッセージだけでなく、追加のLNプロトコルメッセージのバッチ処理を可能にする試みです。
● LDK #3792は、TRUCトランザクションとエフェメラルアンカーに依存する v3コミットメントトランザクション（ニュースレター #325参照）の初期サポートを、テストフラグの下、導入します。ノードは、ゼロ以外の手数料率を設定するopen_channel提案を拒否し、そのようなチャネルを自分から開始しないことを保証し、後の手数料引き上げのためにまずUTXOを確保するためにv3チャネルを自動的に受け入れるのを停止します。このPRではまた、TRUCトランザクションは10 kvB未満でなければならないため、チャネルあたりのHTLC数の制限が483から114に引き下げられました。
● LND #9127では、lncli addinvoiceコマンドに--blinded_path_incoming_channel_listオプションが追加されました。これにより、受取人は、支払人がブラインドパスで転送を試みるための 1つ以上（複数のホップの場合）の優先チャネルIDを埋め込むことができます。
● LND #9858は、RBFによる協調クローズフロー（ニュースレター #347参照）のプロダクション機能ビット61のシグナリングを開始し、Eclairとの相互運用性を適切に実現します。この機能をテストするノードとの相互運用性を維持するため、ステージングビット161は保持されます。
● BOLTs #1243は、BOLT11仕様を更新し、p（ペイメントハッシュ）、 h（説明のハッシュ）、s（シークレット）などの必須フィールドの長さが正しくない場合、読み取り人（支払人）はインボイスの支払いを行ってはならないことを示しました。これまでは、ノードはこの問題を無視できました。このPRではまた、 Low R署名は1 byteのスペースを節約できるが、仕様では強制されないことを説明する注記をサンプルセクションに追加しています。

もっと知りたいですか？

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