今週のニュースレターでは、トランザクションを直接マイナーに送信することについての議論と、 ウォレットの実装に推奨されるTaprootのTest Vectorのセットへのリンクの掲載に加えて、 Taprootの準備について、新しいリリースとリリース候補、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点についての恒例のセクションも含まれています。

ニュース

  • ● マイナーに直接トランザクションを送信する: Lisa Neigutは、Bitcoin-Devメーリングリストで、P2Pトランザクションリレーネットワークを廃止し、 ユーザーがマイナーに直接トランザクションを送信する可能性についてスレッドを立ち上げました。 この動作モードの利点として提案されたのは、必要な帯域幅の削減、プライバシーの向上、 RBFやCPFPのパッケージルールの複雑さの解消、 次のブロックの手数料率のコミュニケーションの改善などでした。 しかし、何人かは反対しました:

    • ● 必要な帯域幅: 2016年から使用されているCompact Block Relayでは、 未承認トランザクションを受信したノードが、そのトランザクションがブロックに含まれている場合に、 最小限の帯域幅のオーバーヘッドにより再受信をスキップできることを、いくつかの回答が指摘しています。 今後提案されているErlayなどの改良により、 未承認トランザクションリレーによる帯域幅のオーバーヘッドをさらに小さくすることができます。

    • ● プライバシーの向上: マイナーにのみトランザクションを送信することで、承認前のトランザクションは公開されなくなりますが、 Pieter Wuilleは、マイナーにネットワークの特権ビューも提供することになると主張しています。 公的な透明性が望ましいでしょう。

    • ● RBF、CPFPとパッケージの複雑さ: ノードオペレーターはマイナーよりもリソースを消費する攻撃に敏感であることは確かですが、 Gloria Zhaoは、これは主に程度の問題であると指摘しています。 同じ攻撃がより大規模に実行されるとマイナーにも影響が及ぶため、 ノードがすでに採用しているのと同じタイプの防御策がマイナーにも必要になるでしょう。

    • ● 手数料率のコミュニケーション: Bitcoin Coreが手数料率を推定するために使用している現在の方法は、 未承認トランザクションを受信し、それが承認済みブロックで確認できるまでの時間を確認することに基づいています。 これはリアルタイムの手数料率の情報よりも遅れがありますが、 Pieter Wuilleは、マイナーに弱いブロック（チェーンに追加するのに十分なproof of workを持っていないブロック）をブロードキャストさせるなど、 以前から提案されている他の方法を使うことで改善できると提案しています。 弱いブロックは、PoWが有効なブロックよりも頻繁に発生するため、 マイナーが現在取り組んでいるトランザクションに関するより新しい情報を提供することができます。

    直接的な反論に加えて、現行システムのいくつかの利点が指摘されています:

    • ● マイナーの匿名性: 現在50,000台以上のノードがすべてのトランザクションをリレーしているため、 マイナーはそれらのノードの1つをひっそりと運用することで必要な情報を簡単に受け取ることができます。 仮名の開発者ZmnSCPxjは、たとえTorのような匿名ネットワーク上であっても、 マイナーに永続的なIDを維持させることで、マイナーの特定が容易になり、 一部のトランザクションを検閲するよう強制することができると提案しました。

    • ● 検閲耐性: 現在、誰もが基本的にあらゆるコンピューターを使ってノードを立ち上げ、 リレーされたトランザクションを受信し、マイニング機器に接続し、マイニングを始めることができます。 Pieter Wuilleは、マイナーに直接送信する場合はそうはならないと指摘しています。 新規マイナーがトランザクションを受信するためには、自分のノードを配信する必要がありますが、 検閲やシビル攻撃の両方に耐性のあるアクセスしやすい方法はありません。 特に、Wuilleは「マイナーが自分の[送信先URL]をオンチェーンで公開する仕組みは役に立ちません。 それは、その公開を検閲しないように他のマイナーに依存するでしょう」と述べています。

    • ● 集中化への耐性: Wuilleはまた、「追加の送信のコストと複雑さは、[各マイナーの]ハッシュレートとは無関係だが、 メリットは[ハッシュレート]に正比例する。」とも述べています。 これにより、「ほとんどのウォレットにとって、 最大規模のいくつかのプールに[トランザクション]を送信することがはるかに容易になり」、 集中化が促進されることになります。

  • ● TaprootのTest Vector: Pieter Wuilleは、Bitcoin-DevメーリングリストにTaprootのBIP341仕様への追加を提案している Test Vectorのセットを投稿しました。 それらは、「key/scriptからのマークルルート / tweak / scriptPubKeyの計算、 key path支払いのsigmsg / sighash / signatureの計算、 script path支払いのcontrol blockの計算をカバーするウォレットの実装」にフォーカスしています。

    Test Vectorはアクティベーション後すぐにTaprootを使えるようにしたいと考え、 実装に取り組んでいる開発者にとって特に有用なものになるはずです。

Taprootの準備 #20: アクティベーション時に何が起こる？

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

この投稿の公開から2週間以内に、Taprootはブロック709,632でアクティベートされる予定です。 何が起こるかは分かっていますし、いくつか起こる可能性のある障害も分かっています。

ベストで最も可能性の高い結果は、すべてがうまくいくことです。 何も起こらなければ、通常のユーザーには何も見えないはずです。 ノードを注意深く観察したり、Taprootトランザクションを作成しようとする人だけがなにかに気づくでしょう。 ブロック709,631では、私たちが認識しているほぼすべてのフルノードが同じコンセンサスルールを適用します。 その1ブロック後、Bitcoin Core 0.21.1、22.0または関連リリースを実行しているノードは、 それより前のソフトウェアリリースでは実行されていなかった追加のTaprootルールを適用します。

これには、ノードソフトウェアの以前のバージョンと新しいバージョンで異なるブロックを受け入れるというリスクが伴います。 これは2015年のBIP66ソフトフォークのアクティベーション中に発生し、 6ブロックのチェーン分岐といくつかの短いチェーン分岐が発生しました。 この問題の再発を防ぐために、かなりの技術的な努力が払われてきました。 同様の問題は、マイナーが意図的にTaprootで無効なブロックをマイニングするか、 Bitcoin Coreや関連ノードソフトウェアにハードコードされた安全対策を無効にした場合にのみTaprootで起こるでしょう。

具体的には、チェーン分岐を発生させるためには、マイナーはTaprootのルールに従わずに （segwit v1アウトプットである）Taprootアウトプットから支払いをするトランザクションを作成または受け入れる必要があります。 マイナーがそうした場合、Bitcoinノードのオペレーターが経済的なコンセンサスから、 Taproot無効ブロックを拒否した場合、マイナーは少なくとも6.25 BTC（執筆時点で約$400,000 USD）を失うことになります。

ノードオペレーターがどうするかは、無効なブロックを作ってみないことには分かりません。 ノードは完全にプライベートに実行できますが、プロキシの測定値では、 ノードオペレーターの50%以上がBitcoin CoreのTaproot適用バージョンを実行していることを示しています。 これはTaproot無効ブロックを作成したマイナーが、ネットワークによって拒否されることを確実にするのに十分すぎるほどでしょう。

非常に可能性は低いですが、一時的なチェーン分岐は理論的には可能です。 ForkMonitor.infoのようなサービスやBitcoin Coreのgetchaintips RPCを使って、分岐を監視することが可能です。 分岐が発生した場合、軽量クライアントは誤った承認を受け取る可能性があります。 2015年のチェーン分岐のように、6承認得ることは理論的に可能ですが、 それはマイナーが250万ドル近い価値を失ったことを意味します（2015年の損失は約5万ドルでした）。 これほど大きな価値がかかっているので、マイナーは半年前に準備を通知したTaprootのルールを実際に適用することが期待できます。

私たちが想像するほぼすべての障害状況において、シンプルで効果的な一時的な対応は、承認数の上限を上げることです。 通常、支払いを受け入れるのに6承認待っている場合、 問題が解決されるか、さらに高い承認数が必要であることが明確になるまでの数時間、 承認数を30回にすぐに上げることができます。

フルノードオペレーターの経済的なコンセンサスからTaprootのルールを適用すると確信しているユーザーやサービスにとっては、 さらにシンプルな解決策として、どのトランザクションが承認されたかという情報のみを Bitcoin Core 0.21.1以降（まてあは互換性のあるノード実装）から取得することができます。

Optechでは、Taprootのアクティベーションはスムーズに進むと予想していますが、 取引所やブロック709,632付近で大きな金額を受け入れる人は、 ノードをアップグレードするか、問題の兆候がある場合には承認数の上限を一時的に引き上げる準備をすることを勧めています。

リリースとリリース候補

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

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

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 BDK、Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #23306では、Address ManagerがIPアドレス毎に複数のポートをサポートできるようになりました。 歴史的に、Bitcoin Coreは固定ポート8333を使用し、自動的にアウトバウンド接続をする際にこのポートのアドレスを強く推奨してきました。 この動作は、（Bitcoinネットワーク上でアドレスをゴシップする）非BitcoinサービスのDoSから、 Bitcoinノードが利用されるのを防ぐのに役立つと示唆されていますが、 ネットワークトラフィックを観察することでBitcoinノードを簡単に検出することもできます。 それぞれの（IPとポート）の組み合わせを個別のアドレスとして扱うことで、 将来的にアドレスをより統一的に扱うことができます。

  • ● C-Lightning #4837では、--max-dust-htlc-exposure-msat設定オプションが追加され、 金額がdust limitを下回る保留中のHTLCの合計残高を制限します。 詳細については、Rust-Lightningの同様のオプションについての以前の記事をご覧ください。

  • ● Eclair #1982では、ノードオペレーターの対応を必要とする重要な通知を集めた新しいログファイルを導入しました。 付属のリリースノートによると、notifications.logがノードオペレーターが監視すべきものです。

  • ● LND #5803では、支払いユーザーが繰り返し支払いするための追加の手順を実行しなくても、 同じAtomic Multipath Payment (AMP)インボイスへの 複数のSpontaneous paymentが可能になりました。 同じインボイスへの複数の支払いを受け取る機能は、 既存の簡略化されたマルチパス支払いの実装では不可能なAMPの機能です。

  • ● BTCPay Server #2897は、支払い方法としてLNURL-Payのサポートを追加し、 Lightningアドレスのサポートも有効にしています。