今週のニュースレターには、Taprootをアクティベートするためのコードの最近の進捗状況のまとめと、 最近のBitcoin Core PR Review Clubミーティングの解説や、 人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更点など恒例のコーナーが含まれています。

ニュース

  • ● Taprootアクティベーションの議論: 以前のニュースレター #139で Taprootのソフトフォークのアクティベーション方法に関する議論を紹介して以来、 アクティベーションに興味のある人たちの間でSpeedy Trialの提案が注目されています。 これに関して、BIP9のバリエーションを使用するPR#21377と、 BIP8の一部となった変更を使用するPR#21392の２種類のPRが公開されました。 これらのPRの主な技術的な違いは、スタートポイントとストップポイントの指定方法です。 PR#21377はMedian Time Past (MTP)を使用し、PR#21392は現在のブロックの高さを使用します。

    MTPは通常、Bitcoinのメインネットワーク(mainnet)と、testnetやデフォルトsignetおよび さまざまな個別のsignetなどのテストネットワーク間でほぼ均一です。 これにより、複数のネットワークでブロックの高さが大きく異なっていても、１つのアクティベーションパラメータを共有でき、 mainnetのコンセンサスの変更に伴う同期について、これらのネットワークのユーザーの作業を最小限に抑えることができます。

    残念ながら、MTPは少数のマイナーによる小さな操作や、大多数のハッシュレートによる大きな操作が容易にできてしまいます。 またブロックチェーンの再編成の際に、偶然、過去の時間に戻ってしまうこともあります。 それに比べて、高さは異常な再編成がお起きた場合にのみ減少します1。 このため、通常レビュー担当者は高さは永遠に増加するだけであるという単純化された仮定をたてることができ、 MTPの仕組みよりも高さベースのアクティベーションの仕組みを分析するのが簡単になります。

    他の懸念の中でもとりわけ、このような２つの提案のトレードオフは、一部の開発者の間で、 どちらかのPRが追加のレビューを受けられず最終的にいずれかがBitcoin Coreにマージされることを妨げると考えられ、 行き詰まりをみせました。この行き詰まりは、2つのPRの作成者がが妥協案に合意したことで、 アクティベーションの議論の一部の参加者が満足する形で解決しました:

    1. ノードがソフトフォークのブロックシグナリングのカウントを開始する時間にMTPを使用し、 開始時間後の次の2,016ブロックのリターゲット期間の開始時にカウントを開始します。 これはBIP9のversion bitsと、 BIP148のUASFがソフトフォークのアクティベートを支援した際のブロックのカウント開始方法と同じです。

    2. ノードがまだロックインされていないソフトフォークのブロックシグナリングのカウントを止める際もMTPを使用します。 ただし、BIP9とは異なり、MTPのストップ時間はカウントが実行されたリターゲット期間の終了時にのみチェックされます。 これによりアクティベーションの試行がstartedからfailedへ直接遷移する機能が削除され、 分析が簡素化され、マイナーがアクティベーションのシグナルを送信できる完全な2,016ブロックの期間が、 すくなくとも１回はあることが保証されます。

    3. 最小のアクティベーションパラメータに高さを使用します。これにより分析がさらに簡素化され、 また複数のテストネットワークでアクティベーションパラメータを共有できるようにする目標とも互換が残ります。 これらのネットワークで高さが違っていても、MTPで定義された期間内でアクティベートされるため、 すべてのネットワークで最小のアクティベーションの高さ0を使用できます。

    議論の参加者の中には、この妥協案に不満を表す人もいましたが、その実装は現在、 Bitcoin Coreの10人以上のアクティブなコントリビューターと、 他の２つのフルノード実装（btcdとlibbitcoin）のメンテナからのレビューや支持の表明を受けています。 我々はTaprootをアクティベートするためのこの勢いが続くことを願い、 今後のニュースレターで追加の進展を報告できるようにしたいと考えています。

Bitcoin Core PR Review Club

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

Introduce deploymentstatusは、 Anthony TownsによるPR (#19438)で、 ソフトフォークのアクティベーション状態をチェックするコード・パスをすべて変更せずに将来のデプロイメントを埋め込むための ３つのヘルパー関数を提案しています: DeploymentEnabledはデプロイメントをアクティブにできるかどうかをテストします。 DeploymentActiveAtは指定されたブロックでデプロイメントを適用する必要があるかどうかをチェックし、 DeploymentActiveAfterは次のブロックでデプロイメントを適用する必要があるかどうか確認します。 3つすべてが、Buriedデプロイメントとversion bitsデプロイメントの両方で機能します。

Review Clubの議論は、変更とその潜在的な利点を理解することにフォーカスしました。

  • BIP9 version bitsデプロイメントに対するBIP90 Buriedデプロイメントの利点は何ですか？

    Buriedデプロイメントは、ソフトフォークの適用を規定するテストを単純な高さのチェックに置き換えることで、 デプロイメントロジックを簡素化し、コンセンサス変更のデプロイメントに関係する技術的負債を削減します。 ➚

  • このPRで列挙されているBuriedデプロイメントはいくつありますか？

    コインベースの高さ、CLTV (CHECKLOCKTIMEVERIFY)、Strict DER signature、CSV (OP_CHECKSEQUENCEVERIFY)およびSegwitの5つです。 これらは、PRで提案されたsrc/consensus/params.h#L14-22の BuriedDeployment列挙型にリストされています。 Satoshi時代のソフトフォークも 埋めこめられていると言えるでしょう。 ➚

  • 現在version bitsのデプロイメントはいくつ定義されていますか？

    testdummyとschnorr/taproot (BIPs 340-342)の２つで、 src/consensus/params.h#L25-31内のコードベースに列挙されています。 ➚

  • Taprootのソフトフォークがアクティベートされ、後でそのアクティベーション方法を埋め込みたい場合、このPRがマージされるとBitcoin Coreにどのような変更が必要ですか？

    主な変更は、現在のコードと比べて大幅に簡素化されます: DEPLOYMENT_TAPROOTの行をDeploymentPos列挙型からBuriedDeployment列挙型に移動します。 最も重要なのは、検証ロジックを変更する必要がないということです。 ➚

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

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

  • ● Bitcoin Core #21594では、getnodeaddresses RPCにnetworkフィールドを追加し、 さまざまなネットワーク（IPv4、IPv6、I2P、onionなど）上のノードを識別しやすくしています。 作者は、これは将来のgetnodeaddressesのパッチで、特定のネットワークの引数を取り、 そのネットワークのアドレスのみを返すための基礎となることも提案しています。

  • ● Bitcoin Core #21166では、signrawtransactionwithwalletRPCが改良され、 ウォレットが所有していない他の署名済みインプットを持つトランザクションのインプットに署名できるようになりました。 以前は、ウォレットが所有していない署名済みのインプットを持つトランザクションがRPCに渡されると、 そのインプットのwitnessが壊れたトランザクションが返されてました。 他で署名されたインプットを持つトランザクションのインプットに署名することは、 トランザクション手数料を上げるためにインプット/アウトプットを追加するなど、 さまざまな状況で役立ちます。

  • ● LND #5108では、低レベルのsendtorouteRPCを使ったSpontaneous Atomic Multipath Payment (Original AMPとも呼ばれる) のサポートが追加されました。Original AMPでは、送信者がすべてのプリイメージを選択するため、 本質的に非対話型（自発的）です。送信者のプリイメージの選択は、 単一パスのSpontaneous paymentで使用されてきたkeysend形式のSpontaneous Paymentの一部でもあります。 今後のPRでは、高レベルのsendpaymentRPCでSpontaneous Multipath Paymentを利用できるようにすることが期待されています。

  • ● LND #5047では、ウォレットがBIP32拡張公開鍵(xpubs)をインポートし、 それをLNDのオンチェーンウォレットへの支払いの受け取りに使用できるようになりました。 PSBTをサポートするLNDの最近のアップデート（ニュースレター #118参照）と組み合わせることで、 LNDはチャネル資金を持たないwatch-onlyウォレットとして機能できるようになります。 例えば、アリスはコールドウォレットからxpubをインポートし、 LNDが指定したアドレスを使ってそのウォレットに資金をデポジットし、 LNDにチャネルの開設を要求し、そのチャネルを開設するPSBTにコールドウォレットで署名し、 チャネルが閉じられた際はLNDが自動的にコールドウォレットにデポジットした資金を戻すことができます。 最後の、閉じたチャネルのデポジット資金をコールドウォレットに戻す部分は、 特に非協力的に閉じた場合に追加の手順が必要になるかもしれませんが、 この変更によりLNDは、 PSBTと互換性のあるコールドウォレットやハードウェアウォレットとの完全な相互運用に向けて大きく前進しました。

脚注

  1. もし、ブロックチェーンのすべてのブロックが同じ個別のProof of Work（PoW）を持っているとしたら、 最も多くのPoWを持つ有効なチェーンは、最新のブロックの高さが最も高い、最も長いチェーンになります。 しかし、Bitcoinのプロトコルは、2,016ブロック毎に、新しいブロックに含めるPoWの量を調整し、 ブロックの間の平均時間を10分前後に保つために作業を増やしたり減らしたりしています。 つまり、ブロックの数が少ないチェーンが、 ブロックの数が多いチェーンよりもPoWが多くなる可能性があるということを意味します。

    Bitcoinのユーザーはお金を受け取ったかどうか判断するのに、 ブロック数ではなくPoWが最も多いチェーンを使用します。ユーザーは、 そのチェーンで末端のブロックの一部が異なるブロックに置き換えられた異なるチェーンを発見すると、 現在のチェーンよりもPoWが多ければ、その再編成されたチェーンを使用します。 再編成されたチェーンはより多くのPoWが累積しているにもかかわらず、含まれるブロックの数は少ない場合があるので、 チェーンの高さは減少する可能性があります。

    これは理論上の懸念ですが、通常は実用上の問題ではありません。高さの減少は、 再編成が2,016ブロックのセットと別の2,016ブロックのセットとの間のリターゲット境界の少なくとも１つを超える場合にのみ可能です。 また、多数のブロックを含む再編成や、必要なPoWの量の直近の大きな変化（直近のハッシュレートの大きな増減、 もしくはマイナーによる観察可能な操作）を必要とします。BIP8の文脈では、 高さを減少させる再編成は、典型的な再編成よりもアクティベーション中のユーザーに影響を与えることはないと考えています。 ↩