今週のニュースレターでは、LNの仕様から最近のノードには関係のなくなった詳細を削除する提案と、 mempoolポリシーに関する限定週刊シリーズの最後から2つめの記事を掲載しています。 さらに、Bitcoin Core PR Review Clubの要約や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

• ● LN仕様のクリーンアップの提案: Rusty Russellは、 最近のLN実装でサポートされなくなったいくつかの機能を削除し、 他の機能は常にサポートされることを前提とした提案を行うPRを Lightning-Devメーリングリストに投稿しました。 提案された変更に関連して、Russellはゴシップメッセージにしたがってパブリックノードの機能を調査した結果も提供しています。 彼の結果は、ほぼすべてのノードが次の機能をサポートしていることを示唆しています:

  • ● 可変サイズのOnionメッセージ: TLV（Type-Length-Value）フィールドを使用するように仕様が更新されたのとほぼ同時に、 2019年に仕様の一部になりました（ニュースレター #58参照）。 これは、各ホップが固定長のメッセージを使用し、ホップ数を20に制限していた暗号化Onionルーティングの元のフォーマットを置き換えるものです。 可変サイズのフォーマットにより、任意のデータを特定のホップにリレーすることが非常に容易になりました。 唯一の欠点は、メッセージ全体のサイズが一定のままなので、送信するデータ量が増えると最大ホップ数が減ることです。

  • ● ゴシップクエリ: 2018年に仕様の一部になりました（BOLTs #392参照）。 これにより、ノードはネットワーク上の他のノードによって送信されたゴシップメッセージのサブセットのみをピアに要求できるようになりました。 たとえば、ノードは、帯域幅を節約し処理時間を短縮するために、古い更新を無視して、 最近のゴシップの更新のみを要求する場合があります。

  • ● Data Loss Protection: 2017年に仕様の一部になりました（BOLTs #240参照）。 この機能を使用するノードは、再接続時に最新のチャネルステートに関する情報を送信します。 これにより、ノードがデータを失ったことを検知できる可能性があり、 データを失っていないノードに最新のステートでチャネルを閉じるように促すことができます。 詳細については、ニュースレター #31をご覧ください。

  • ● Static remote-party key: 2019年に仕様の一部になりました（ニュースレター #67参照）。 これにより、ノードは、すべてのチャネルの更新でノードの非HTLC資金を 同じアドレスに送信することをコミットするように要求できます。 以前は、チャネルの更新毎に異なるアドレスが使用されていました。 この変更後、このプロトコルをオプトインしてデータを失ったノードは、 ほとんどの場合、最終的にHDウォレットなど、 選択したアドレスで少なくとも資金の一部を受け取ることになります。

  クリーンアップ提案のPRに対する最初の返信は好意的なものでした。

承認を待つ #9: ポリシーの提案

トランザクションリレーや、mempoolへの受け入れ、マイニングトランザクションの選択に関する限定週刊シリーズです。 Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持っている理由や、 ウォレットがそのポリシーを最も効果的に使用する方法などが含まれます。

先週の記事では、アンカーアウトプットと CPFP carve outについて説明しました。 これにより、どちらのチャネル参加者も、協力することなく共有されたコミットメントトランザクションの手数料を 引き上げることができます。このアプローチには、まだいくつかの欠点があります。 アンカーアウトプットを作成するためにチャネル資金が拘束され、 コミットメントトランザクションの手数料率は、mempoolの最小手数料率を満たすことを保証するために、 通常過大に支払われ、CPFP carve outでは追加の子孫は１つしか認められません。 アンカーアウトプットでは、Coinjoinやマルチパーティコントラクトプロトコルなど、 ２人よりも多い参加者間で共有されるトランザクションの手数料の引き上げを保証することはできません。 この記事では、これらの制限やその他の制限に対処するための現在の取り組みについて説明します。

パッケージリレーには、トランザクショングループの転送と検証を可能にする P2Pプロトコルとポリシーの変更が含まれています。 これは、コミットメントトランザクションがmempoolの最小手数料率を満たしていない場合でも、 子によるコミットメントトランザクションの手数料の引き上げを可能にします。 さらに、パッケージRBF は、子トランザクションによる 競合する親トランザクションの置換のための手数料の引き上げを可能にします。 パッケージリレーは、ベースプロトコルレイヤーにおける一般的な制限を取り除くように設計されています。 しかし、共有トランザクションの手数料の引き上げにおけるその有用性から、 特定のユースケースにおけるPinningを排除するための多くの取り組みも生まれています。 たとえば、パッケージRBFは、コミットメントトランザクションがそれぞれの手数料引き上げの子トランザクションと一緒にブロードキャストされる際に、 相互に置換できるため、各コミットメントトランザクションに複数のアンカーアウトプットは必要なくなります。

注意すべき点は、既存のRBFルールでは、置換トランザクションには、 置換されるすべてのトランザクションによって支払われる合計手数料よりも高い手数料を支払う必要があるという点です。 このルールは、置換の繰り返しによるDoSを防ぐのに役立ちますが、 悪意あるユーザーが、低手数料率であるものの手数料額は高い子トランザクションをアタッチすることで、 トランザクションを置換する際のコストを増加させることを可能にします。 これは、高手数料率パッケージによるトランザクションの置換を不当に阻止することで、 トランザクションがマイニングされるのを妨げるものであり、よく「ルール３Pinning」と呼ばれています。

開発者はまた、署名済みトランザクションに手数料を追加する全く異なる方法を提案しています。 たとえば、SIGHASH_ANYONECANPAY | SIGHASH_ALLを使用してトランザクションのインプットに署名することで、 トランザクションブロードキャスターは、アウトプットを変更することなく、トランザクションにインプットを追加して手数料を提供できます。 しかしながら、RBFには置換トランザクションがより高い「マイニングスコア」を持つこと（つまり、より速くブロックに選択される）を 要求するルールがないため、攻撃者は低手数料率の祖先に邪魔される置換トランザクションを作成することで、 この種のトランザクションをPinning可能です。 トランザクションおよびトランザクションパッケージのマイニングスコアの正確な評価を複雑にしているのは、 既存の祖先と子孫の制限が、この計算の計算量を制限するには不十分であることです。 接続されているトランザクションは、トランザクションがブロックに選択される順序に影響を与える可能性があります。 クラスター とよばれる完全に接続されたコンポーネントは、現在の祖先と子孫の制限があれば、 任意のサイズにすることができます。

一部のmempoolの欠陥とRBFのPinning攻撃に対処するための長期的な解決策は、 mempoolのデータ構造を再構築して、 祖先と子孫のセットだけでなくクラスターを追跡することです。これらのクラスターのサイズは制限されます。 クラスターの制限により、ユーザーが未承認のUTXOを使用できる方法が制限されますが、 祖先スコアベースのマイニングアルゴリズムを使用してmempool全体を線形化し、 ブロックテンプレートを極めて迅速に構築し、置換トランザクションのマイニングスコアが 置換されるトランザクションよりも高いという要件を追加することは可能になります。

それでも、トランザクションリレーの幅広いニーズと期待に応えるための単一のポリシーセットは存在しない可能性があります。 たとえば、バッチ処理された支払いは、多数の未承認の子孫を必要とするかもしれませんが、 これは総手数料を通じて共有トランザクションのパッケージRBFをPinningする余地を残します。 v3トランザクションリレーポリシーの提案は、 コントラクトプロトコルがより制限的なパッケージ制限のセットをオプトインできるようにするために開発されました。 v3トランザクションは、サイズ2（親1つ子1つ）のパッケージのみを許可し、子のweightを制限します。 これらの制限は、総手数料を通じたRBF Pinningを緩和し、 mempoolの再構築を必要とせずにクラスターmempoolのメリットの一部を提供します。

エフェメラルアンカーは、v3トランザクションとパッケージリレーの特性をベースに、 アンカーアウトプットをさらに改善するための提案です。これは、手数料ゼロのv3トランザクションに属するアンカーアウトプットが、 手数料を引き上げる子トランザクションによって使用される場合に限り、ダスト制限から免除されます。 手数料ゼロのトランザクションは、正確に1つの子トランザクションによって手数料を引き上げる必要があるため （そうしないと、マイナーはそれをブロックに含めるインセンティブを得られません）、 このアンカーアウトプットは「エフェメラル」であり、UTXOセットの一部にはなりません。 エフェメラルアンカーの提案により、チャネルクローズトランザクションの手数料供給メカニズムとして CPFPを使用したLN symmetryが実現可能になります。 また、このメカニズムは、3人以上の参加者で共有されるトランザクションにも利用可能です。 開発者は、bitcoin-inquisitionを使用してエフェメラルアンカーをデプロイし、 signet上でこれらのマルチレイヤーの変更を構築してテストするためのソフトフォークを提案しています。

この記事で強調されたPinningの問題は、昨年、メーリングリストやプルリクエスト、 ソーシャルメディア、直接の会議を通じてRBFポリシーを改善するための豊富な議論や提案を生み出しました。 開発者は、小さな修正から完全な刷新に至るまで、さまざまな解決策を提案し、実装しました。 -mempoolfullrbfオプションは、Pinningの懸念とBIP125実装の不一致に対処することを意図したもので、 トランザクションリレーポリシーにおけるコラボレーションの難しさと重要性を浮き彫りにしました。 1年前にbitcoin-devメーリングリストで会話を始めるなど、一般的な手段を使って コミュニティを巻き込もうとする真摯な努力がされましたが、 既存のコミュニケーションや意思決定の方法が意図した結果を生んでおらず、改善が必要であることは明らかでした。

非中央集権的な意思決定は困難なプロセスですが、Bitcoinのトランザクションリレーネットワークを利用する プロトコルやアプリケーションの多様なエコシステムをサポートするためには必要です。 来週は、このシリーズの最終回で、読者の皆さんにこのプロセスへの参加と改善を奨励していただきたいと考えています。

Bitcoin Core PR Review Club

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

Stop relaying non-mempool txsは、Marco Falke (MarcoFalke)によるPRで、 大量のメモリ消費を引き起こす可能性があり、もはや必要ないか、少なくとも非常に僅かなメリットしかない インメモリデータ構造であるmapRelayを削除することで、Bitcoin Coreクライアントを簡素化するものです。 このマップには、mempoolにある場合も、ない場合もあるトランザクションが含まれており、 ピアからのgetdataリクエストに返信するために使用されることがあります。

• mapRelayを削除する理由は何ですか？

  このデータ構造のメモリ消費量には制限がありません。通常、メモリ使用量は多くありませんが、 データ構造のサイズが外部エンティティ（ピア）の動作によって決定され、最大値がない場合、 DoS脆弱性が発生する可能性があるため懸念されています。 ➚

• なぜmapRelayのメモリ使用量は判断しにくいのですか？

  mapRelay内の各エントリーは、トランザクション（CTransaction）への共有ポインタであり、 mempoolには別のポインタが保持されている可能性があります。 同じオブジェクトへの２つめのポインタは、単一のポインタと比較して、ほとんど追加のスペースを使用しません。 共有トランザクションがmempoolから削除されると、そのスペースはすべてmapRelayエントリーに帰属するようになります。 つまり、mapRelayのメモリ使用量は、トランザクションの数やその個々のサイズにだけ依存するのではなく、 mempoolに存在しなくなったトランザクションの数にも依存するため、予測が困難です。 ➚

• m_most_recent_block_txsを導入することでどのような問題が解決されるのですか？（これは、最後に受信したブロックのトランザクションのみのリスト）

  これが無いと、mapRelayが利用できないため、mempoolから削除されてしまうので、 （最新のブロックで）マイニングされたばかりのトランザクションを要求するピアに提供できなくなります。 ➚

• mapRelayを何も置き換えずにただ削除するのではなく、m_most_recent_block_txsを導入する必要があると思いますか？

  この質問については、Review Clubの出席者の間でもいくらか不確実なものでした。 m_most_recent_block_txsがブロックの伝播速度を向上させる可能性があるという意見がありました。 これは、受信したばかりのブロックをまだピアが持っていない場合、 我々のノードのそのトランザクションを提供する機能が ピアのCompact Blockを完成させるのに役立つ可能性があるからです。 もう１つの意見は、チェーン分岐の場合に役立つかもしれないというものでした。 ピアが私たちとは異なる先頭を持つ場合、ブロックを介してそのトランザクションを持っていない可能性があります。 ➚

• m_most_recent_block_txsのメモリ要件は、mapRelayと比較してどうですか？

  m_most_recent_block_txs内のエントリー数は、ブロック内のトランザクション数によって制限されます。 ただし、m_most_recent_block_txsのエントリーは（トランザクションへの）共有ポインタであり、 また（すでに）m_most_recent_blockによってポイントされているため、 メモリ要件は、トランザクション数よりも少なくなります。 ➚

• この変更の結果、トランザクションが以前よりも短期間、もしくは長期間利用可能になるシナリオはありますか？

  最後のブロックからの時間が15分（mapRelayにエントリーが残っている時間）を超える場合は長くなり、 それ以外の場合は短くなります。15分という時間はかなり恣意的なものであるため、これは許容できると思われます。 ただし、この変更により、非ベストチェーンに固有のトランザクションが保持されなくなるため、 1ブロックを超えるチェーン分岐が発生した場合（これは非常に稀ですが）、 トランザクションの可用性が低下する可能性があります。 ➚

リリースとリリース候補

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

• ● LND v0.16.4-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の注目すべき変更点。

• ● Bitcoin Core #27869は、ニュースレター#125や #172、#230で言及したように、 ユーザーがレガシーウォレットからディスクリプターに移行するのを支援するために、 Bitcoin Core #20160で概説されている継続的な取り組みの一環として、 レガシーウォレットをロードする際に非推奨の警告を出すようにしました。