今週のニュースレターでは、HTLCエンドースメントのテストを開始する提案と、 ライトニングサービスプロバイダー（LSP）の仕様案に関するフィードバックの要請、 デュアル・ファンディングを使用する際のゼロ承認チャネルの開設に関する課題の議論、 Payjoinトランザクションの高度な応用に関する提案、 最近のBitcoin Core開発者の対面ミーティングの要約のリンクを掲載しています。 今週のニュースレターでは、トランザクションリレーとmempoolに含める際のポリシーに関する新シリーズの第一弾を掲載し、 また新しいリリースとリリース候補の発表（libsecp256k1のセキュリティリリースを含む）や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも掲載しています。

ニュース

  • ● HTLCエンドースメントのテスト: 数週間前、Carla Kirk-CohenとClara Shikhelmanは、 チャネルジャミング攻撃の緩和策の一環として、 HTLCエンドースメント（ニュースレター #239参照） のアイディアをテストするために計画している次のステップについて、 Lightning-Devメーリングリストに投稿しました。 最も注目すべきは、実験的なフラグを使用して展開できる短い仕様案を提供し、 その展開が不参加ノードとの相互作用に何も影響を与えないようにしたことです。

    実験者によって展開されると、このアイディアの建設的な批判の1つである、 転送された支払いが実際にどの程度この方式でブーストされるかという問いに答えることが容易になるはずです。 LNのコアユーザーが同じ経路で頻繁にお互いに支払いを送り合っており、 レピュテーションシステムが計画通りに機能すれば、 チャネルジャミング攻撃を受けてもコアネットワークは機能し続ける可能性が高くなります。 しかし、ほとんどの支払人が支払いを稀にしか送らない場合（あるいは高額な支払いなど、 最も重要なタイプの支払いを稀にしか送らない場合）、レピュテーションを構築するのに十分な交流が得られないか、 レピュテーションデータがネットワークの現在の状態から大きく遅れてしまうでしょう（ レピュテーションが有用でなくなるか、あるいは悪用されるようになるでしょう）。

  • ● LSPの仕様案に関するフィードバックのお願い: Severin Bühlerは、 LSP（Lightning Service Provider）とそのクライアント（通常は非転送LNノード）間のインターオペラビリティに関する 2つの仕様についてフィードバックの要請をLightning-Devメーリングリストに投稿しました。 1つめの仕様は、クライアントがLSPからチャネルを購入できるようにするためのAPIを定義しています。 2つめの仕様は、JIT（Just-In-Time）チャネルをセットアップ・管理するためのAPIを定義しています。 JITチャネルは、仮想ペイメントチャネルとして機能するチャネルで、 仮想チャネルへの最初の支払いを受け取ると、LSPは、 承認されるとチャネルをオンチェーンにアンカリングするトランザクションをブロードキャストします（通常のチャネルにします）。

    開発者のZmnSCPxjは返信で、LSPのオープンな仕様に賛成しています。 彼は、クライアントが複数のLSPに接続しやすくなり、ベンダーロックインを防ぎ、 プライバシーを向上させることができると指摘しています。

  • ● デュアル・ファンディング時のゼロ承認チャネルの課題: Bastien Teinturierは、デュアル・ファンディングプロトコルを使用する際に、 ゼロ承認チャネルを許可する際の課題について、 Lightning-Devメーリングリストに投稿しました。 ゼロ承認チャネルは、チャネル開設トランザクションが承認される前でも使用することができます。 これは、いくつかのケースではトラストレスです。デュアル・ファンディングチャネルは、 チャネル開設トランザクションにチャネルの両参加者のインプットが含まれるチャネルを含む デュアル・ファンディングプロトコルを使用して作成されたチャネルです。

    ゼロ承認は、一方の参加者がチャネル開設トランザクションのすべてのインプットを制御する場合にのみトラストレスです。 たとえば、アリスがチャネル開設トランザクションを作成し、チャネルでボブに資金を渡し、 ボブはその資金をアリスを介してキャロルに支払おうとします。 アリスは、最終的に承認されるトランザクションを自分が制御していることを知っているので、 支払いを安全にキャロルに転送することができます。しかし、チャネル開設トランザクションにボブのインプットもある場合、 ボブは、競合するトランザクションを承認させることができ、 それによりチャネル開設トランザクションの承認が妨げられ、 アリスはキャロルに転送した資金の補償を受けられなくなります。

    この記事を書いている時点では、参加者が満足するようなものはありませんでしたが、 デュアル・ファンディングによるゼロ承認チャネルの開設を可能にするためのいくつかのアイデアが議論されました。

  • ● 高度なPayjoinの応用: Dan Gouldは、 Payjoinプロトコルを使用して単純な支払いの送受信以上のことをするためのいくつかの提案を、 Bitcoin-Devメーリングリストに投稿しました。 その提案の中で、最も興味深いと思った2つの提案は、 プライバシーとスケーラビリティを向上させ、手数料コストを削減するための古いアイディアである トランザクション・カットスルーのバージョンでした:

    • ● 支払いの転送: アリスはボブに支払う代わりに、 ボブのベンダー（キャロル）に支払い、ボブのキャロルに対する債務を減らします（もしくは将来予想される請求の前払い）。

    • ● 支払いの一括転送: アリスはボブに支払う代わりに、ボブが支払う債務を持つ（または信用を築きたい）複数の人に支払います。 Gouldの例では、安定した入出金の流れがある取引所を想定しています。 Payjoinでは、可能な限り新しい入金によって引き出しの支払いを行うことができます。

    これらの技術はどちらも、少なくとも2つのトランザクションを1つのトランザクションに減らすことができ、 かなりのブロックスペースを節約することができます。バッチ処理を使用する場合は、 さらに大きなスペースの節約が可能です。元の受信者（たとえばボブ）の観点からすると、 元の支払人（たとえばアリス）が手数料の一部または全額を支払うことができるのはさらに良いことです。 スペースや手数料の節約に加えて、トランザクションをブロックチェーンから削除し、 受け取りや支払いなどの操作を組み合わせることで、ブロックチェーンの監視組織が資金の流れを確実に追跡することが著しく困難になります。

    この記事を書いている時点では、メーリングリストでの議論はありませんでした。

  • ● Bitcoin Core開発者の対面ミーティングの要約: Bitcoin Coreに取り組んでいる開発者たちは、 プロジェクトのいくつかの側面について議論するために最近ミーティングを行いました。 そのミーティングでのいくつかの議論のメモが公開されました。 議論されたトピックは、ファズテストやassumeUTXO、ASMap、 サイレント・ペイメント、libbitcoinkernel、 リファクタリングおよびパッケージリレーなどです。 また、特別な注意を払うべきと思われる2つのトピックも議論されました:

    • ● Mempool Clusteringは、 トランザクションとそのメタデータがBitcoin Coreのmempoolに保存される方法の大幅な再設計に関する提案をまとめたものです。 このメモでは、現在の設計に関するいくつかの問題について説明し、 新しい設計の概要を示し、関連するいくつかの課題とトレードオフを示しています。 設計の説明とプレゼンテーションのスライドのコピーが後に公開されました。

    • ● Project Meta Discussionは、 プロジェクトの目標や、内外の多くの課題があるなかで、それらを達成するための方法についての議論をまとめたものです。 議論の一部は、バージョン25以降の次のメジャーリリースに向けて、 よりプロジェクトにフォーカスしたアプローチをとるなど、すでにプロジェクトの管理に実験的な変化をもたらしています。

承認を待つ #1: なぜmempoolがあるのか？

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

Bitcoinネットワークの多くのノードは、未承認のトランザクションをインメモリのプール、 つまり mempool に保存しています。このキャッシュは、各ノードにとって重要なリソースであり、 ピアツーピアのトランザクションリレーネットワークを可能にしています。

トランザクションリレーに参加するノードは、ブロックを急激にではなく徐々にダウンロードし検証します。 ブロックが見つかる約10分ごとに、mempoolを持たないノードは帯域幅のスパイクが発生し、 その後、各トランザクションを検証するための計算負荷の高い期間が続きます。 一方、mempoolを持つノードは、通常、ブロック内のすべてのトランザクションをすでに確認しており、 それらをmempoolに保存しています。 コンパクトブロックリレーを使用すると、 これらのノードは、ブロックヘッダーとショートIDをダウンロードするだけで、 あとは自分のmempool内のトランザクションを使用してブロックを再構築します。 コンパクトブロックのリレーに使用されるデータ量は、ブロックのサイズに比べればごくわずかです。 ノードはすでに署名とスクリプトを検証し（かつキャッシュし）、タイムロックの要件を計算し、 必要に応じてディスクから関連するUTXOをロードしているため、トランザクションの検証もはるかに高速化されています。 また、ノードはブロックを他のピアに迅速に転送できるため、ネットワーク全体の ブロック伝播速度が劇的に向上し、ブロックが古くなるリスクも低減します。

また、mempoolは独立した手数料推定器を構築するためにも使用できます。 ブロックスペースの市場は手数料ベースのオークションであり、 mempoolを保持することで、ユーザーは他の人がどんな入札をしているか、 過去にどのような入札が成功したかをより正確に把握することができます。

しかし、すべての人にとって共通のmempoolというものは存在しません。 各ノードは異なるトランザクションを受信する可能性があります。 あるノードにトランザクションを送信したとしても、それが必ずマイナーにも届くとは限りません。 このような不確実性をもどかしく思うユーザーもいます。 「なぜ、マイナーに直接トランザクションを送信しないのか？」と疑問に思う人もいます。

すべてのトランザクションがユーザーから直接マイナーに送信されるBitcoinネットワークを考えてみましょう。 少数の事業者に対して、各トランザクションに対応するIPアドレスを記録し、 特定のパターンに一致するトランザクションの受け入れを拒否するよう要求することで、 金融活動を検閲し監視することができます。このようなBitcoinは、 ときにはより便利かもしれませんが、Bitcoinの最も重要な特性のいくつかが失われてしまいます。

Bitcoinの検閲耐性とプライバシーは、ピアツーピアのネットワークに由来します。 トランザクションをリレーするために、各ノードは匿名のピアのセットに接続します。 これらのピアは、マイナーである可能性もあれば、マイナーに接続されている誰かかもしれません。 この方法は、トランザクションがどのノードから発信され、 どのノードがそのトランザクションの承認を担当しているのかを難読化するのに役立ちます。 特定のエンティティを検閲したいと思う人は、マイナーや人気のある取引所、 または他の中央集権型の送信サービスを標的にするかもしれませんが、なにかを完全にブロックするのは難しいでしょう。

未承認トランザクションの一般的な可用性は、ブロックプロデューサーになるための参入コストを最小限に抑えるのにも役立ちます。 選択された（または除外された）トランザクションに不満を持つ人は、すぐにマイニングを開始することができます。 各ノードをトランザクションのブロードキャスト候補として平等に扱うことで、 トランザクションとその手数料への特権的なアクセスをどのマイナーにも与えないようにすることができます。

まとめると、mempoolは、ノードがブロックのダウンロードと検証のコストを時間的に分散させ、 ユーザーがより良い手数料の見積もりにアクセスできるようにする非常に有用なキャッシュです。 ネットワークレベルでは、mempoolは分散トランザクションとブロックのリレーネットワークをサポートします。 これらの利点はすべて、マイナーがブロックに含める前にすべてのトランザクションを誰でも確認することができる時に最も顕著になります。 他のキャッシュと同様に、mempoolは「ホット」なときに最も有用で、メモリに収めるためにサイズを制限する必要があります。 来週のセクションでは、最も有用なトランザクションをmempoolに保持するための指標として、 インセンティブの互換性の使用について検討します。

リリースとリリース候補

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

  • ● Libsecp256k1 0.3.2は、ECDHにlibsecpを使用し、 かつGCCバージョン13以上でコンパイルされる可能性のあるアプリケーションのためのセキュリティリリースです。 作者の説明によると、新しいバージョンのGCCでは、 一定時間で実行されるように設計されたlibsecpのコードを最適化しようとするため、 特定の状況下でサイドチャネル攻撃を実行することが可能になります。 Bitcoin CoreはECDHを使用していないため、影響を受けません。 今後、コンパイラの将来の変更によって同様の問題が発生する可能性がある場合に、 それを検知し、事前に変更を行うことができるようにするための作業が進められています。

  • ● Core Lightning 23.05rc2は、このLN実装の次期バージョンのリリース候補です。

  • ● Bitcoin Core 23.2rc1は、Bitcoin Coreの前のメジャーバージョンのメンテナンスリリースのリリース候補です。

  • ● Bitcoin Core 24.1rc3は、Bitcoin Coreの現在のバージョンのメンテナンスリリースのリリース候補です。

  • ● Bitcoin Core 25.0rc2は、Bitcoin Coreの次期メジャーバージョンのリリース候補です。

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

今週の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 #26076は、公開鍵の導出パスを表示するRPCメソッドを更新し、 強化導出ステップを示すためにシングルクォート'ではなくhを使用するようにしました。 この変更により、ディスクリプターのチェックサムが変更されることに注意してください。 秘密鍵を含むディスクリプターを処理する場合、ディスクリプターが生成またはインポートされた時と同じシンボルが使用されます。 レガシーウォレットの場合、getaddressinfoのhdkeypathフィールドとウォレットのダンプのシリアライズ形式は変更されていません。

  • ● Bitcoin Core #27608は、他のピアからブロックが提供された場合でも、 ピアからブロックのダウンロードを試行し続けるようにしました。 Bitcoin Coreは、受信したブロックの1つがディスクに書き込まれるまで、 そのブロックを持っていると主張するピアからブロックをダウンロードし続けます。

  • ● LDK #2286では、ローカルウォレットが管理するアウトプットのための PSBTの作成と署名を可能にしました。

  • ● LDK #1794では、デュアル・ファンディングのサポートを開始し、 デュアル・ファンディングに使用される対話型のファンディング・プロトコルに必要なメソッドを追加しました。

  • ● Rust Bitcoin #1844は、BIP21 URIのスキーマを小文字、つまりbitcoin:にしました。 URIスキーマの仕様（RFC3986）では、スキーマは大文字小文字を区別しないとされていますが、 テストの結果、いくつかのプラットフォームでは、大文字のBITCOIN:が渡された場合に、 bitcoin: URIを処理するために割り当てられたアプリケーションを開かないことがわかりました。 大文字が正しく処理されるようになれば、より効率的なQRコードの作成が可能になります（ニュースレター#46を参照）。

  • ● Rust Bitcoin #1837は、新しい秘密鍵を生成する関数を追加し、 以前はより多くのコードを必要としたものを簡素化しました。

  • ● BOLTs #1075は、ノードがピアから警告メッセージを受け取った後にピアとの接続を解除しないよう仕様を更新しました。