今週のニュースレターでは、LNノードが常に秘密鍵をオンラインにしておかなくても支払いを受け取れるようにする提案を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、 新しいソフトウェアのリリースおよびリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • 秘密鍵をほぼオフラインのままLN支払いを受け取る: 2019年、開発者のZmnSCPxjは、支払いを受け入れるためのネットワークの帯域幅とレイテンシーを削減する、 保留中のLN支払い(HTLC)をカプセル化する別の方法を提案しました。 最近、Lloyd Fournierがこのアイディアを利用して、秘密鍵をオンラインにしておかなくても、 ノードが複数のLN支払いを受け入れることができるようにすることができると提案しました。 しかし、このアイディアにはいくつかの欠点があります。

    • ノードは必要に応じてペナルティトランザクションを送信するために秘密鍵を必要とします。

    • ノードが秘密鍵を使用せずに受け取った支払いが多いほど、 チャネルが一方的に閉じられた際に、より多くのオンチェーン手数料を支払う必要があります。

    • 受信ノードはプライバシーを失うことになります。つまり、 そのノードが単なるルーティング・ホップではなく、支払いの最終的な受信者であることを 近隣のピアが判断できるようになります。 しかし、支払いをルーティングしない一部のエンドユーザーノードにとっては、 これはすでに明らかな場合があります。

    これらの制限の中で、アイディは実行可能と思われ、今週メーリングリストでは、 ZmnSCPxjが分かりやすいプレゼンテーションを行い、そのバリエーションが議論されました。 Fournier laterは、アイディアの改善を提案しました

    アイディアを実装するには、いくつか重要なLNプロトコルの変更が必要になるため、 ユーザーが短期または中期的に利用できるようになることはなさそうです。 ただし、LNの受信ノードがオンラインで鍵を保持する必要性を最小限に抑えたいと考えている人は、 このアイディアを調査することをお勧めします。

Bitcoin Core PR Review Club

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

Prune g_chainman usage in auxiliary modulesは、 Carl DongによるリファクタリングPR(#21767)で、 コンセンサスエンジンのモジュール化の第一歩として、 g_chainmanを非グローバル化するプロジェクトの一部です。 これにより、コンポーネントが分離され、より焦点を絞ったテストが可能になります。 長期的な目標は、コンセンサスエンジンを非コンセンサスコードから完全に分離することです。

Review Clubの議論は、コードの変更について深く掘り下げる前に、以下のような一般的な質問から始まりました:

  • このPRはリファクタリングであり、機能的な動作を変更してはいけません。 それを検証するには、どのような方法がありますか?

    コードを注意深くレビューすること、テストを実行すること、テストのカバレッジを追加すること、 assertやカスタムログを挿入すること、--enable-debugでビルドすること、 変更を加えたbitcoindを実行すること、GDBやLLDBなどのデバッガでコードをステップ実行することなどです。 

  • このPRは、Bitcoin Coreのコンセンサスエンジンをモジュール化して分離するというより大きなプロジェクトの一部です。 これにはどんなメリットがありますか?

    そうすることで、コードの推論、保守、構成およびテストが容易になります。 セキュリティとメンテナンス性のために最小限のAPIを公開し、非グローバルデータを渡すための設定オプションを提供できます。 さまざまな設定でそれらのオブジェクトをより細かく制御できるように、 可変パラメータを使用してコンポーネントを構築できます。 

  • ChainstateManagerの責務は何ですか?

    ChainstateManagerクラスは、1つまたは2つのchainstate( Initial Block Download (IBD)とオプションのスナップショット)を作成し操作するためのインターフェースを提供します。 

  • CChainStateは何をするのですか?

    CChainStateクラスは、現在の最長チェーンを保存し、 その状態に関するローカルの情報を更新するためのAPIを提供します。 

  • CChainクラスとは何ですか?

    CChainクラスは、メモリ内のインデックスされたブロックのチェーンです。 ブロックインデックスポインターのvectorが含まれています。 

  • BlockManagerの責務は何ですか?

    BlockManagerクラスは、m_block_indexに保存されたブロックのツリーを維持し、 これを参照して最も作業の多いチェーンの先頭を探します。 

  • cs_mainとは何ですか?

    cs_mainは、バリデーション固有のデータ(および今のところ、他の多くのもの)を保護するためのmutexです。 名前は、critical section mainを意味し、main.cppのデータを保護するものです。 現在、validation.cppおよびnet_processing.cppにあるコードは、 以前はmain.cppという1つのファイルにありました。 

  • 概念的に、コードベースの”Validation”部分には何が含まれるのでしょうか?

    Validationは、ブロックチェーンと関連するUTXOセットの最長のビューを格納、維持します。 また未承認トランザクションをmempoolに登録するインターフェースも含まれます。 

リリースとリリース候補

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

  • LND 0.13.0-beta.rc5は、プルーニングされたBitcoinフルノードの使用をサポートし、 Atomic MultiPath (AMP)を使用した支払いの送受信を可能にし、 PSBT機能の向上、その他の改善およびバグ修正を行ったリリース候補です。

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

今週のBitcoin CoreC-LightningEclairLNDRust-Lightninglibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBitcoin Improvement Proposals(BIP)、および Lightning BOLTsの注目すべき変更点。

  • Bitcoin Core #22051では、 Taprootアウトプットのdescriptor をBitcoin Coreウォレットにインポートするためのサポートを追加しています。 このPRは、ウォレットユーザーがTaprootアウトプットで資金を受け取れるようにし、 ユーザーがTaprootをアウトプットを受け取り使用できるようにする完全なサポートを実装する 公開中のPRの前提条件になります。

  • Bitcoin Core #22050は、バージョン2のTor onion service(Hidden service)のサポートを止めました。 バージョン2のサービスは既に非推奨で、Torプロジェクトは9月にアクセスできなくなることを発表しています。 Bitcoin Coreは既にバージョン3のonion serviceをサポートしています(ニュースレター #132 参照)。

  • Bitcoin Core #22095では、Bitcoin CoreがBIP32秘密鍵を導出する方法をチェックするテストが追加されています。 Bitcoin Coreでは常にこれらの鍵を正しく導出していましたが、 最近他のウォレットが32バイト未満の拡張秘密鍵(xpriv)のパディングに失敗したことで、 128個の鍵のうち1つ以上を誤って導出していることが判明しました。 これは資金の損失やセキュリティの低下に直接つながるものではありませんが、 あるウォレットでHDウォレットのシードを作成し、それを別のウォレットにインポートする、もしくは マルチシグウォレットを作成するユーザーにとっては問題になります。 このPRで実装されたTest Vectorは、 将来のウォレット作成者がこの問題を回避できるようBIP32にも追加されています

  • C-Lightning #4532では、チャネルのアップグレードの実験的なサポートを追加しています。 最新のコミットメントトランザクションを再構築することで、 例えばTaprootを使用するように変換するといった、 新機能や構造的な変更を組み込めるようになります。 プロトコルは休止要求で始まり、 どちらの参加者も休止期間が終わるまで状態の更新を送信しないという合意をします。 この期間、ノードは自分たちがしたい変更をネゴシエートし、それを実行します。 最後に、チャネルは完全な動作状態に戻ります。 C-Lightningでは現在、チャネルが既に強制的な非アクティブ期間にある場合の接続の再確立中にこれを実装しています。 チャネルのアップグレードについては、さまざまな提案がニュースレター #108で議論され、 このPRの作者はニュースレター #109に掲載された “simplified HTLC negotiation”に取り組むのもあって、この機能を望んでいます。 このPRにより、C-Lightningが2019年に初めてサポートした option_static_remotekeyニュースレター #64参照) を利用できるよう古いチャネルをアップグレードすることができます。

  • LND #5336では、新しいPayment Secretを指定することで、 ユーザーがAMPインボイスを非対話的に再利用できる機能を追加しています。 また、前述の再利用の仕組みを促進するために、 LNDで作成されたAMPインボイスのデフォルトのインボイス有効期限も30日に引き上げられています。

  • BTCPay Server #2474では、すべての通常のフィールド(ダミーデータ)を含む偽のイベントを送信することで Webhookをテストする機能が追加されています。 これは、StripeやCoinbase Commerceのような中央でホストされているBitcoinのペイメントプロセッサで利用できるテスト機能を反映してます。