今週のニュースレターでは、Dark Skippy高速シード流出攻撃についての発表と、 ブロック保留攻撃と提案された解決策に関する議論、コンパクトブロックの再構築に関する統計、 Pay-to-Anchorアウトプットを持つトランザクションに対する置換サイクル攻撃についての説明、 FROSTによる閾値署名を定義する新しいBIPへの言及、 提案中の2つのソフトフォークを使用しゼロ知識証明を楽観的に検証できるようにするEftraceの改良に関する発表を掲載しています。

ニュース

  • ● より高速なシード流出攻撃: Lloyd FournierとNick FarrowおよびRobin Linusは、 Bitcoinの署名デバイスから鍵を流出させる改良された方法であるDark Skippyを発表しました。 この方法は、前もって約15社のハードウェア署名デバイスベンダーに責任をもって開示されていました。 鍵の流出は、トランザクションの署名コードが、秘密鍵やBIP32 HDウォレットのシードといった 基盤となる鍵マテリアルに関する情報を漏らすような方法で意図的に署名を作成する際に発生します。 攻撃者がユーザーのシードを入手すると、いつでもユーザーの資金を盗むことができます（攻撃者が迅速に行動すれば、 流出につながったトランザクションで使用された資金も含む）。

    著者らは、彼らが知る限り、これまで最高の鍵流出攻撃は、BIP32シードを流出させるために数十の署名が必要だったと述べています。 Dark Skippyを使用すると、2つの署名でシードを流出させることができます。 2つの署名は2つのインプットを持つ単一のトランザクションに属している可能性があります。 つまり、ユーザーが最初に資金を使用しようとした瞬間に、ユーザーの資金すべてが危険にさらされる可能性があります。

    鍵の流出は、ソフトウェアウォレットを含む、署名を作成するロジックであればどれでも使用できますが、 悪意のあるコードを含むソフトウェアウォレットは、 そのシードをインターネット経由で攻撃者に送信するだけであることが一般的に予想されます。 流出は主に、インターネットに直接アクセスできないハードウェア署名デバイスのリスクであると考えられています。 ファームウェアまたはハードウェアロジックのいずかによってロジックが破損したデバイスは、 デバイスがコンピューターに接続されていない場合でも（たとえば、すべてのデータがNFCやSDカード、 QRコードを使用して転送される場合など）シードを素早く流出させることができます。

    Bitcoinで流出耐性のある署名を実行する方法については議論されており（ Optechニュースレターのニュースレター #87など）、 現在私たちが認識している2つのハードウェア署名デバイスに実装されています（ニュースレター #136参照）。 その導入された方法では、標準的なシングルシグへの署名と比較して、ハードウェア署名デバイスとの余分な通信の往復が必要になりますが、 ユーザーが、追加の通信の往復を必要とするスクリプトレスマルチシグなどの他の種類の署名に慣れれば、 そのデメリットは小さくなるかもしれません。別のトレードオフを提供する流出耐性のある署名の代替方法も知られていますが、 私たちの知る限り、Bitcoinのハードウェア署名デバイスに実装されているものはありません。

    Optechは、多額の資金を保護するためにハードウェア署名デバイスを使用するすべての人に、 流出耐性のある署名を使用するか、複数の独立したデバイス（たとえばスクリプトや、スクリプトレスマルチシグや閾値署名など）を使用することで、 破損したハードウェアやファームウェアから保護することを推奨しています。

  • ● ブロック保留攻撃と潜在的な解決策: Anthony Townsは、ブロック保留攻撃、関連する無効シェア攻撃および、 両方の攻撃に対する潜在的な解決策（Stratum v2でのクライアントの作業選択の無効化と 不明瞭なシェア化を含む）についての議論をBitcoin-Devメーリングリストに投稿しました。

    プールマイナーは、 シェア と呼ばれる作業単位の送信に対して報酬を得ます。 シェアはそれぞれ、一定量のPoW（Proof of Work）を含む 候補ブロック です。 これらのシェアの既知の部分にも、候補ブロックが最もPoWの多いブロックチェーンに含めるのに十分なPoWが含まれていることが期待されます。 たとえば、シェアのPoWの目標値が有効なブロックのPoW目標値の1/1,000である場合、 プールは平均して、有効ブロックを生成する毎に1,000シェアに支払うことになります。 古典的なブロック保留攻撃は、プールマイナーが有効なブロックを生成する1,000 分の1のシェアを送信せず、 有効ブロックではない999のシェアを送信する場合に発生します。 これによりマイナーは、作業の99.9%に対して報酬を受け取ることができますが、 プールはそのマイナーから収入を得ることができません。

    Stratum v2には、マイナーが候補ブロックにプールがマイニングを提案するものとは異なるトランザクションセットを含めることができるように、 プールが有効にできるオプションモードが含まれています。プールマイナーは、 プールが持っていないトランザクションのマイニングを試みることもできます。 各シェアには、プールがまだ確認したことのないトランザクションが最大数MB含まれている可能性があり、 そのすべてが検証に時間がかかるように設計されている可能性があります。 これにより、プールのインフラが簡単に圧迫され、正直なユーザーからのシェアを受け入れる能力に影響を及ぼす可能性があります。

    プールは、トランザクションの検証をスキップしてシェアのPoWのみを検証することでこの問題を回避することができますが、 これによりプールマイナーは無効なシェアを送信したことに対して100%の確率で支払いを回収できるため、 古典的なブロック保留攻撃から支払いを回収できる確率の約99.9%よりも若干悪くなります。

    このため、プールはクライアントによるトランザクションの選択を禁止にするか、 プールマイナーに永続的な公開ID（政府発行の文書により検証された名前など）の使用を求めて、 悪質な行為者を追放するインセンティブが生まれます。

    Townsが提案する1つの解決策は、プールが複数のブロックテンプレートを提供し、 各マイナーが好みのテンプレートを選択できるようにすることです。 これは、Ocean Poolが使用している既存のシステムと似ています。 プールが作成したテンプレートに基づいて送信されたシェアは、最小限の帯域幅で迅速に検証できます。 これにより100%が支払われる無効なシェア攻撃を防ぐことができますが、 約99.9%の利益をもたらす、ブロック保留攻撃には役立ちません。

    ブロック保留攻撃に対処するために、Townsは概念的に単純なハードフォークによって、 プールマイナーが特定のシェアに有効なブロックとなるのに十分なPoWがあるかどうかを知ることを阻止し、 それらを 不明瞭なシェア にする方法を説明した、2011年にMeni Rosenfeldが最初に提案したアイディアを更新します。 有効なブロックのPoWとシェアPoWを区別できない攻撃者は、 攻撃者がシェアによる収入を奪うのと同じ割合でのみ有効なブロックの収入をプールから奪うことができます。 このアプローチには以下の欠点があります:

    • ● SPVで確認可能なハードフォーク: すべてのハードフォークの提案は、 すべてのフルノードのアップグレードを要求します。しかし（BIP103のような単純なブロックサイズの増加提案など）多くの提案は、 SPV（Simplified Payment Validation）を使用する軽量クライアントのアップグレードを必要としません。 この提案では、ブロックヘッダーのフィールドの解釈方法が変更されるため、 すべての軽量クライアントもアップグレードが必要になります。Townsは、 必ずしも軽量クライアントのアップグレードを必要としない代替案を提示していますが、 そのセキュリティは大幅に低下します。

    • ● プールマイナーにプールのプライベートテンプレートの使用を要求: 100%無効なシェア攻撃を防ぐためにテンプレートが必要になるだけでなく、 そのテンプレートを使用して生成されたすべてのシェアが受信されるまで、 プールはプールマイナーからそのテンプレートを秘密にしておく必要があります。 プールはこれを利用してマイナーを騙し、マイナーが反対するトランザクションのPoWを生成させることができます。 しかし、監査を可能にするために、期限切れのテンプレートを公開することはできます。 最近のプールのほとんどは、数秒ごとに新しいテンプレートを生成するため、 監査はほぼリアルタイムで実行でき、悪意あるプールが数秒以上マイナーを騙すのを防止できます。

    • ● シェアの送信を求める: （特定の動作モードの）Stratum v2の利点の1つは、プールのブロックを見つけた正直なプールマイナーが、 それをすぐにBitcoin P2Pネットワークにブロードキャストできるため、 対応するシェアがプールサーバーに到達する前でも伝播を開始できることです。 不明瞭なシェアの場合、シェアはプールが受け取り、ブロードキャストする前に完全なブロックに変換される必要があります。

    Townsは、最後にブロック保留攻撃を解決する2つの動機について説明しています。 この攻撃は大規模なプールよりも小規模なプールに影響を与えること、 匿名マイナーを許可しているプールを攻撃するコストはほとんどかからないこと、 一方、マイナーの身元確認を義務付けているプールは既知の攻撃者を禁止できることです。 ブロック保留を解決することで、Bitcoinマイニングがより匿名化され、分散化される可能性があります。

  • ● コンパクトブロックの再構築に関する統計: 開発者の0xB10Cは、コンパクトブロックの再構築の最近の信頼性について Delving Bitcoinに投稿しました。2016年にBitcoin Core 0.13.0にこの機能が追加されて以来、 多くのリレーフルノードがBIP152コンパクトブロックリレーを使用しています。 これにより、未承認トランザクションを共有している2つのピアは、 新しいブロックでそれらのトランザクションが承認された際に、トランザクション全体を再送信するのではなく、 それらのトランザクションへの短い参照を使用できます。これにより帯域幅が大幅に削減され、 レイテンシーも削減されるため、新しいブロックがより迅速に伝播します。

    新しいブロックの伝播が速くなると、偶発的なブロックチェーンのフォークの数が減少します。 フォークが減ると、無駄になるPoW（Proof of Work）の量が減り、 小規模なマイニングプールよりも大規模なマイニングプールに有利な ブロックレース の数も減り、 Bitcoinのセキュリティと分散性が向上します。

    ただし、新しいブロックには、ノードがまだ見たことのないトランザクションが含まれる場合があります。 その場合、コンパクトブロックを受信するノードは通常、送信ピアにそれらのトランザクションを要求し、 ピアが応答するのを待つ必要があります。これによりブロックの伝播が遅くなります。 ノードがブロック内のすべてのトランザクションを取得するまで、そのブロックを検証することも、 ピアにリレーすることもできません。これにより、偶発的なブロックチェーンのフォーク頻度が増加し、 PoWセキュリティが低下し、集中化の圧力が高まります。

    そのため、コンパクトブロックが、追加のトランザクションを要求することなく、 新しいブロックを検証するために必要なすべての情報を提供する頻度を監視することは有用です。 これを 成功した再構築 と呼びます。Gregory Maxwellは最近、 Bitcoin Coreをデフォルト設定で実行しているノードの成功した再構築が減少したことを報告しました。 特に、mempoolfullrbf設定を有効にして実行しているノードと比較した場合です。

    開発者0xB10Cの今週の投稿では、さまざまな設定の独自のノードを使用して観察した 成功した再構築の数をまとめており、一部のデータは6ヶ月前まで遡ります。 mempoolfullrbfを有効にした場合の効果に関する最近のデータは、約1週間前までしか遡りませんでしたが、 Maxwellのレポートと一致しています。これはBitcoin Coreの次期バージョンでmempoolfullrbfをデフォルトで有効にするための プルリクエストを検討する動機付けとなりました。

  • ● Pay-to-Anchorに対する置換サイクル攻撃: Peter Toddは、 エフェメラルアンカーの提案の一部であるP2A（Pay-to-Anchor）アウトプットタイプについて Bitcoin-Devメーリングリストに投稿しました。P2Aは、 誰でも使用できるトランザクションアウトプットです。これは特にLNなどのマルチパーティプロトコルで CPFPによる手数料の引き上げに役立ちます。ただし、 LNでのCFPFによる手数料の引き上げは現在、悪意ある取引相手が2段階のプロセスで実行する 置換サイクル攻撃に対して脆弱です。彼らは、 まず正直なユーザーのトランザクションを同じトランザクションの取引相手のバージョンに置き換えます。 次に置き換えたトランザクションを、どちらのユーザーのトランザクションのバージョンとも関係のないトランザクションに置き換えます。 LNチャネルに未解決のHTLCがある場合、置換サイクルが成功すると、 取引相手がそれを正当な参加者から盗むことができます。

    LNの現在のアンカーアウトプットチャネルタイプを使用すると、 取引相手のみが置換サイクルを実行できます。しかし、Toddは、P2Aでは誰でもアウトプットを使用できるため、 それを使用するトランザクションに対して誰でも置換サイクル攻撃を実行できると指摘しています。 それでも攻撃から利益を得ることができるのは取引相手だけであるため、 第三者がP2Aアウトプットを攻撃する直接的なインセンティブはありません。 攻撃者が自分のトランザクションを正直なユーザーのP2Aを使用した支払いよりも高い手数料率でブロードキャストすることを計画し、 攻撃者が途中の状態をマイナーに承認されることなく置換サイクルを正常に完了した場合、攻撃は無料になる可能性があります。 置換サイクル攻撃に対する既存のLNの緩和策（ニュースレター #274参照）はすべて、 P2A置換サイクルの阻止に対して同等に効果があります。

  • ● スクリプトレス閾値署名用のBIPの提案: Sivaram Dhakshinamoorthyは、 BitcoinのSchnorr署名の実装用のスクリプトレス閾値署名を作成するため、 BIPの提案をBitcoin-Devメーリングリストに投稿しました。 これにより、（ChillDKGを使用するなどして）セットアップ手順を既に実行している署名者のセットは、 それらの証明者の動的なサブセットとのやりとりのみを必要とする署名を安全に作成することができます。 署名は、シングルシグのユーザーやスクリプトレスマルチシグのユーザーによって作成されたSchnorr署名とオンチェーン上で区別がつかず、 プライバシーとファンジビリティが向上します。

  • ● CATとMATTおよびElftraceを使用したゼロ知識証明の楽観的検証: Johan T. Halsethは、彼のツールElftraceがゼロ知識（ZK）証明を検証できるようになったことを Delving Bitcoinに投稿しました。これをオンチェーンで使用するには、 OP_CATとMATTの両方のソフトフォークがアクティベートされる必要があります。

Bitcoin Core PR Review Club

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

Add PayToAnchor(P2A), OP_1 <0x4e73>, as standard output script for spendingは、instagibbsによるPRで、 新しいTxoutType::ANCHORアウトプットスクリプトタイプを導入します。 アンカーアウトプットは（bc1pfeessrawgfというアドレスになる） OP_1 <0x4e73>というアウトプットスクリプトを持ちます。これらのアウトプットを標準にすると、 アンカーアウトプットを使用するトランザクションの作成とリレーが簡単になります。

  • このPRでTxoutType::ANCHORが定義される前は、scriptPubKeyOP_1 <0x4e73>はどのTxoutTypeに分類されていましたか？

    これは1 byteのプッシュopcode（OP_1）と2 byteのデータプッシュ（0x4e73）で構成されているため、 有効なv1 witnessアウトプットです。ただ32 byteではないため、WITNESS_V1_TAPROOTの条件は満たさず、 デフォルトでTxoutType::WITNESS_UNKNOWNになります。 ➚

  • 前の質問の回答に基づくと、このアウトプットタイプを作成することは標準的でしょうか？ それを使用することはどうでしょうか？（ヒント：IsStandardとAreInputsStandardはこのタイプをどのように扱うでしょう？）

    （アウトプットをチェックするのに使用される）IsStandardは、TxoutType::NONSTANDARDのみを非標準とみなすため、 これを作成するのは標準になります。AreInputsStandardは、 TxoutType::WITNESS_UNKNOWNを支払いに使用するトランザクションを非標準とみなすため、 それを使用するトランザクションは標準にはなりません。 ➚

  • このPRの前のデフォルトの設定では、標準トランザクションでどのアウトプットタイプを作成できますか？ これは標準トランザクション内でインプットとして使用されるスクリプトタイプと同じですか？

    TxoutType::NONSTANDARDを除くすべての定義済みTxoutTypeを作成できます。 TxoutType::NONSTANDARDとTxoutType::WITNESS_UNKNOWNを除くすべての定義済みTxoutTypeが 支払いに使用できます（ただし、TxoutType::NULL_DATAを支払いに使用することはできません）。 ➚

  • ライトニングネットワークのトランザクションに触れずにアンカーアウトプットを定義してください（より一般的なものに）

    アンカーアウトプットは、ブロードキャスト時にCPFPを介して手数料を追加できるようにするために、 事前署名済みのトランザクションで作成される追加のアウトプットです。詳細については、 トピックのアンカーアウトプットをご覧ください。 ➚

  • アンカーアウトプットのアウトプットスクリプトのサイズが重要なのはなぜですか？

    アウトプットスクリプトが大きいと、トランザクションのリレーと優先順位付けのコストが高くなります。 ➚

  • P2Aアウトプットの作成と使用にはどれくらいの仮想byteが必要ですか？

    P2Aアウトプットの作成に13 vbyte、使用に41 vbyteが必要です。 ➚

  • 3つめのコミットでIsWitnessStandardにif (prevScript.IsPayToAnchor()) return falseを 追加しています。これは何をするもので、なぜ必要なのですか？

    アンカーアウトプットがwitnessデータなしでのみ使用できることを保証します。 これにより、攻撃者が正当な支払いトランザクションを取得して、witnessデータを追加し、 絶対手数料額は高いが手数料率が低い状態でそれを伝播するのを防止します。 それが防止されないと正直なユーザーはそれを置換するためにさらに高い手数料を支払わざるを得なくなります。 ➚

リリースとリリース候補

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

  • ● Libsecp256k1 0.5.1は、このBitcoin関連の暗号関数ライブラリのマイナーリリースです。 署名用の事前計算済みテーブルのデフォルトサイズをBitcoin Coreのデフォルトと一致するように変更し、 （バージョン2暗号化P2Pトランスポートで使用されるプロトコルである） ElligatorSwiftベースの鍵交換のサンプルコードを追加しています。

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

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

最近の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 #30493は、フルRBFをデフォルトの設定として有効にし、 ノードオペレーターがオプトインRBFに戻すオプションを残しています。フルRBFでは、 BIP125の通知に関係なく、未承認のトランザクションを置き換えることができます。 これは、2022年7月からBitcoin Coreのオプションになっています（ニュースレター#208参照）が、 これまではデフォルトで無効になっていました。フルRBFをデフォルトにすることに関する議論については、 ニュースレター#263をご覧ください。

  • ● Bitcoin Core #30285は、クラスターmempoolプロジェクトに 2つの主要なクラスターリニアライゼーションアルゴリズムを追加します。 既存のリニアライゼーションを組み合わせるためのMergeLinearizationsと、 追加処理によってリニアライゼーションを改善するPostLinearizeです。このPRは、 先週のニュースレター#314で掲載された取り組みに基づいています。

  • ● Bitcoin Core #30352は、新しいアウトプットタイプP2A（Pay-To-Anchor）を導入し、 その支払いへの使用を標準にします。このアウトプットタイプは鍵が不要（誰でも使用可能）で、 txidのマリアビリティに耐性のあるCPFPによる手数料の引き上げ用の コンパクトなアンカーを可能にします（ニュースレター #277参照）。 TRUCトランザクションと組み合わせることで、 CPFP carve-outリレールールに基づき、 LNアンカーアウトプットを置き換える エフェメラルアンカーの実装が促進されます。

  • ● Bitcoin Core #29775は、ネットワークをBIP94で定義されているtestnet4に設定する testnet4設定オプションを追加します。testnet4には、 以前のtestnet3でのいくつかの問題の修正が含まれています（ニュースレター #306参照）。 testnet3を使用する既存のBitcoin Coreのtestnet設定オプションは引き続き利用可能ですが、 以降のリリースでは非推奨となり、削除される予定です。

  • ● Core Lightning #7476は、オファーとインボイスのリクエストで長さがゼロの ブラインドパスを拒否する機能を追加することで、 最新のBOLT12仕様の更新案をキャッチアップします。さらに、 ブラインドパスが提供されているオファーでoffer_issuer_idの欠落を許可します。 このような場合は、インボイスの署名に使用された鍵が最終的なブラインドパスの鍵として使用されます。 これは、オファーの発行者がこの鍵にアクセスできると想定しても問題がないためです。

  • ● Eclair #2884は、HTLCエンドースメント用のBLIP4を実装し、 ネットワーク上のチャネルジャミング攻撃を部分的に緩和する最初のLN実装となりました。 このPRにより、受信エンドースメント値のオプションでのリレーが可能になり、 リレーノードは、インバウンドピアの評判のローカルな判断を使用して、 HTLCを次のホップに転送する際にエンドースメントを含めるかどうかを決定します。 ネットワークで広く採用されれば、エンドースされたHTLCは、 流動性やHTLCスロットなどの希少なネットワークリソースへの優先アクセスを得ることができます。 この実装は、ニュースレター#257に掲載した以前のEclairの取り組みに基づいています。

  • ● LND #8952は、チャネルコミットメントのアップグレードの一種である ダイナミックコミットメントを実装するPRのシリーズの一部として、 型付きListを使用するようlnwalletのchannelコンポーネントをリファクタリングしました。

  • ● LND #8735は、addinvoiceコマンドの-blindフラグを使用して、 ブラインドパスでインボイスを生成する機能を追加します。 また、このようなインボイスの支払いも可能になります。BOLT12はまだLNDに実装されていないため、 これはBOLT11インボイスにのみ実装されていることに注意してください。 LND #8764は、（特にマルチパスペイメント（MPP）を実行する）インボイスへの支払いの際に、 複数のブラインドパスの使用を許可することで、以前のPRを拡張します。

  • ● BIPs #1601は、BIP94をマージし、簡単に実行できるネットワーク攻撃を防止することを目的とした コンセンサスルールの改善を含むtestnetの新しいバージョンtestnet4を導入します。 これまでのすべてのmainnetのソフトフォークは、testnet4のジェネシスブロックから有効になり、 使用されるデフォルトポートは48333になります。testnet3で問題のある動作を引き起こした課題を testnet4がどのように解決するかの詳細については、 ニュースレター#306および#311をご覧ください。