今週のニュースレターでは、確率的な支払いに関する継続的な議論の要約と、 LNのエフェメラルアンカースクリプトに関する新しい意見、Bitcoin Coreのオーファンプールからの排除に関する統計、 BIPプロセスの改訂に関するドラフトの更新について掲載しています。また、Bitcoin Core PR Review Clubの要約や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● 確率的な支払いに関する議論の続き: 先週、Oleksandr Kurbatovが Delving BitcoinにOP_RAND opcodeのエミュレートについて投稿した（ ニュースレター #340参照）のを受け、いくつかの議論が始まりました:

    • トリムされたHTLCの代替としての適合性: Dave Hardingは、 Kurbatovの方法が、現在経済的な合理性のない HTLCをルーティングするためにLN-Penaltyや LN-Symmetryのペイメントチャネル内で使用するのに適しているかどうかを尋ねました。 今は、保留中にチャネルが強制閉鎖されるとその金額が失われるトリムされたHTLCが使用されています。 Anthony Townsは、HTLCの解決に使用される対応する役割と逆であるため、 既存のプロトコルの役割では機能しないと考えました。 しかし、彼はプロトコルに手を加えることで、HTLCと整合させることができるかもしれないと考えました。

    • 必要なセットアップ手順: Townsは、 最初に公開されたプロトコルには手順が1つ欠けていることを発見しました。 Kurbatovも同意しました。

    • より単純なゼロ知識証明: Adam Gibsonは、 ハッシュされた公開鍵ではなく、Schnorrと Taprootを使用することで、必要なゼロ知識証明の構築と検証を大幅に簡素化し、 スピードアップできるかもしれないと提案しました。Townsは、 暫定的なアプローチを提案し、Gibsonはそれを分析しました。

    この記事の執筆時点で、議論は続いていました。

  • ● LNのエフェメラルアンカースクリプトに関する議論の続き: Matt Morehouseは、 LNが将来のチャネルでどのエフェメラルアンカースクリプトを使用すべきかについてのスレッド（ ニュースレター #340参照）に返信しました。 彼は、P2Aアウトプットを使用したトランザクションにおける 第三者の手数料の荒らし行為について懸念を表明しました。

    Anthony Townsは、チャネルが時間どおりに閉じられなかったり、適切な状態で閉じられなかったりすると、 相手方が資金を盗む立場になる可能性が高いため、相手方の荒らし行為の方が大きな懸念事項であると指摘しました。 トランザクションを遅らせたり、手数料率を適度に引き上げようとする第三者は、 直接利益を得る手段がない中、資金をいくらか失う可能性があります。

    Greg Sandersは、確率的に考えることを提案しました。 第三者の荒らし行為が最悪の場合、トランザクションのコストが50%増加するとして、 荒らし行為に耐性のある方法を使用すると約10%余分にコストがかかる場合、 5回に1回強制閉鎖するよりも頻繁に第三者の荒らし行為を受けると本当に予想できますか？ 特に、第三者の荒らし行為は資金を失う可能性があり、金銭的な利益を得られないとしたらどうですか？

  • ● オーファンの排除に関する統計: 開発者の0xB10Cは、彼のノードでオーファンプールから排除されたトランザクション数に関する統計を Delving Bitcoinに投稿しました。オーファントランザクションは、 ノードがまだそのすべての親トランザクションを持っていない未承認のトランザクションで、 親トランザクションがなければブロックに含めることができません。Bitcoin Coreでは、 デフォルトで最大100個までオーファントランザクションを保持します。 プールがいっぱいになった後に新しいオーファントランザクションが到着すると、 以前受信したオーファントランザクションが排除されます。

    0xB10Cは、ある日、1,000万を超えるオーファントランザクションが彼のノードから排除され、 ピーク時には1分間に10万件を超える排除率があったことを発見しました。調査の結果、 「このうち99%以上が、このトランザクションと類似しており、 Runestoneの発行（カラードコイン（NFT）プロトコル）に関連している」ことをが分かりました。 同じオーファントランザクションが多数繰り返し要求され、しばらくしてランダムに排除され、 また要求されているようでした。

  • ● BIPプロセスの更新の提案: Mark “Murch” Erhardtは、提案されているBIPプロセスの改訂のドラフトBIPに識別子BIP3が割り当てられ、 追加のレビューの準備が整ったことの発表をBitcoin-Devメーリングリストに投稿しました。 これは、マージされアクティベートされる前の最後のレビューラウンドになる可能性があります。 意見のある方は、プルリクエストにフィードバックを残すことをお勧めします。

Bitcoin Core PR Review Club

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

Cluster mempool: introduce TxGraphは、sipaによるPRで、 TxGraphクラスを導入するものです。このクラスは、 すべてのmempoolトランザクション間の（実効）手数料、サイズ、依存関係に関する知識をカプセル化します。 これは、クラスターmempoolプロジェクトの一部であり、 ミューテーション、インスペクターおよびステージング関数を通じて、 mempoolグラフとの対話を可能にする包括的なインターフェイスを提供します。

特に、TxGraphにはCTransaction、インプット、アウトプット、txid、wtxid、優先順位、 有効性、ポリシールールなどに関する知識はありません。これにより、 クラスの動作を（ほぼ）完全に指定することが容易になり、 PRに含まれているシミュレーションベースのテストが可能になります。

  • mempoolグラフとは何ですか？masterのmempoolコードにはどの程度存在しますか？

    masterでは、mempoolグラフはノードとしてCTxMemPoolEntryオブジェクトのセットとして暗黙的に存在し、 それらの祖先/子孫の関係はGetMemPoolParents()およびGetMemPoolChildren()で再帰的にたどることができます。 ➚

  • TxGraphを持つことの利点は何ですか？欠点はありますか？

    利点は次のとおりです: 1) TxGraphは、クラスターmempoolの実装を可能にし、 そのすべての利点をもたらします。2) mempoolコードをより効率的なデータ構造でカプセル化できます。3) 置換を二重カウントしないなどのトポロジーの詳細を抽象化することで、 mempoolのインターフェースと推論が容易になります。

    欠点は次のとおりです: 1) 導入された大きな変更に関連する多大なレビューとテストの労力。2) たとえばTRUCや他のポリシーに関連するような、トランザクション毎のトポロジー制限を どのように検証で指示できるかが制限されます。3) TxGraph::Ref*ポインタとの間の変換に起因する、 ごくわずかなランタイムパフォーマンスのオーバーヘッド。 ➚

  • TxGraph内で、個々のトランザクションはいくつのClustersに属することができますか？

    トランザクションは概念的には1つのクラスターにしか属せませんが、 答えは2つです。これはTxGraphが2つの並列グラフ（「main」とオプションで「ステージング」）をカプセル化できるためです。 ➚

  • TxGraphがオーバーサイズとはどういう意味ですか？mempoolがいっぱいになることと同じですか？

    TxGraphは、そのClusterの少なくとも1つが、MAX_CLUSTER_COUNT_LIMITを超えると オーバーサイズになります。TxGraphは1つ以上のClusterを持つことができるので、 これはmempoolがいっぱいになることとは異なります。 ➚

  • TxGraphがオーバーサイズになった場合、どの関数が引き続き呼び出され、どの関数が呼び出されないのでしょうか？

    オーバーサイズになったクラスターを実際に実体化する必要がある操作や、 O(n2)以上の作業を必要とする関数はオーバーサイズのClusterでは使用できません。 これには、トランザクションの祖先/子孫を計算するような操作が含まれます。 ミュテーション操作（AddTransaction()、RemoveTransaction()、AddDependency()、 SetTransactionFee()）やTrim()（おおよそO(n log n)）などの操作はまだ許可されています。 ➚

リリースとリリース候補

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

  • ● LND v0.18.5-betaは、この人気のLNノード実装のバグ修正リリースです。 バグ修正は、リリースノートで”important”および”critical”と記載されています。

  • ● Bitcoin Inquisition 28.1は、提案中のソフトフォークやその他の主要なプロトコル変更を 実験するために設計された、このsignetフルノードのマイナーリリースです。 Bitcoin Core 28.1に含まれるバグ修正と、エフェメラルダストのサポートが含まれています。

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

最近の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およびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #25832では、接続の存続期間、IPおよびネットグループによる再接続頻度、 ピアの阻止、排除、不良動作などピア接続イベントを監視するための5つの新しいトレースポイントとドキュメントが追加されました。 Bitcoin Coreユーザーは、提供されているサンプルスクリプトを使用してトレースポイントに接続したり、 独自のトレーススクリプトを作成したりできます（ニュースレター#160および#244参照）。

  • ● Eclair #2989では、ルーターでのバッチスプライシングのサポートが追加され、 1回のスプライシングトランザクションで使用された複数のチャネルを追跡できるようになりました。 新しいチャネルアナウンスをそれぞれのチャネルに決定論的にマッピングできないため、 ルーターは最初に見つかった一致するチャネルを更新します。

  • ● LDK #3440は、（上流ノードが保持する）HTLCのOnionメッセージに埋め込まれた 送信者のインボイスリクエストを検証し、支払いを請求するための正しいPaymentPurposeを生成することで、 非同期支払いの受信のサポートを完了します。 受信した非同期支払いに絶対的な有効期限が設定され、ノードのオンラインステータスの無期限の探索が防止され、 受信ノードがオンラインに戻った時に上流ノードが保持するHTLCをリリースするために必要な通信フローが追加されます。 非同期支払いフローの完全な実装を完了するには、ノードが非同期受信者に代わってインボイスを提供するLSPとしても機能できる必要があります。

  • ● LND #9470は、BumpFeeおよびBumpForceCloseFeeRPCコマンドにdeadline_deltaパラメーターを追加し、 特定の予算（これも指定）が完全に手数料の引き上げに割り当てられ、RBFが実行されるブロック数を指定します。 さらに、conf_targetパラメーターが再定義され、上記のRPCコマンドと非推奨となったBumpCloseFeeの両方について、 現在の手数料率を取得するために手数料推定で照会する際のブロック数を指定します。

  • ● BTCPay Server #6580は、LNURL支払いのBOLT11インボイスにおける説明のハッシュの存在と 正当性を検証するチェックを削除します。この変更は、LNURLドキュメント（LUD）仕様で 提案されている廃止と一致しています。この要件は、 セキュリティ上の利点が最小限である一方、LNURL支払いの実装に大きな課題をもたらすと考えられています。 説明用のハッシュパラメーターフィールドはCore-Lightningで実装されています（ニュースレター #194および#232参照）。

訂正

先週のニュースレターの脚注で、誤って次のように書きました。 「P2SHと提案されているインプットのsigopカウントでは、16個以上の公開鍵を持つOP_CHECKMULTISIGは、 20 sigopsとカウントされるので」これは単純化しすぎでした。実際のルールについては、 今週のAnthony Townsの投稿をご覧ください。