今週のニュースレターでは、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、 新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションを掲載しています。

ニュース

今週は、Bitcoin-DevメーリングリストやLightning-Devメーリングリストでは目立ったニュースはありませんでした。

承認を待つ #8: インターフェースとしてのポリシー

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

本連載ではこれまで、分散型トランザクションリレーの動機と課題を探り、 コンセンサスよりも厳しいトランザクション検証ルールのローカルおよび グローバルな必要性を示しました。 トランザクションリレーポリシーの変更は、アプリケーションのトランザクションがリレーされるかどうかに影響を与えるため、 検討する前に、より広範なBitcoinコミュニティとの交流が必要です。同様に、 トランザクションリレーを利用するアプリケーションやセカンドレイヤープロトコルは、 拒否されるトランザクションを作成しないように、ポリシールールを考慮して設計する必要があります。

オンチェーンでの強制力はトランザクションを迅速に承認できるかどうかに依存するため、 コントラクトプロトコルは優先順位付けに関連するポリシーにさらに密接に依存します。 敵対的な環境では、不正な取引相手はトランザクションの承認を遅らせることに関心を持っている可能性があるため、 トランザクションリレーポリシーのインターフェースの癖がユーザーに対してどのように利用されるかについても考えなければなりません。

ライトニングネットワークのトランザクションは、以前の記事で説明した標準ルールに従います。 たとえば、ピアツーピアプロトコルは、open_channelメッセージでdust_limit_satoshisを指定し、 ダストの閾値を指定します。ダストの閾値より低い金額のアウトプットを含むトランザクションは、 ノードのダスト制限によりリレーされないため、それらの支払いは「オンチェーンで強制力がない」と見なされ、 コミットメントトランザクションから削除されます。

コントラクトプロトコルは、多くの場合、タイムロックされた支払いパスを使用して、 各参加者にオンチェーンで公開されたステートに異議を唱える機会を与えます。 影響を受けるユーザーがその時間内にトランザクションを承認できなければ、資金の損失を被る可能性があります。 このため、手数料は承認の優先度を高めるための主要なメカニズムとして非常に重要ですが、同時により難しくもあります。 手数料率の推定は、トランザクションが後でいつブロードキャストされるかわからず、 ノードがシンクライアントとして動作することが多く、一部の手数料引き上げオプションが利用できないという事実により、複雑になります。 どちらの参加者も共有されたUTXOを一方的に使用することはできないため、 どちらかがオフラインになった場合、コミットメントトランザクションの手数料を引き上げる 置換トランザクションに署名することはできません。 代わりに、LNのコミットメントトランザクションには、 チャネル参加者がブロードキャスト時に手数料引き上げの子トランザクションをアタッチするための アンカーアウトプットを含めることができます。

しかし、この手数料の引き上げ方法にも制限があります。以前の記事で説明したように、 mempoolの最小手数料率がコミットメントトランザクションの手数料率よりも高くなると、 CPFPトランザクションを追加しても効果がないため、将来mempoolの最小手数料率が上昇した場合に備えて、 若干多めに見積もった手数料率で署名する必要があります。 さらに、アンカーアウトプットの開発には、一方の参加者が承認を遅らせることに関心を持っている可能性があるという事実に対する 多くの考慮事項が含まれていました。たとえば、一方の参加者（アリス）は、 オフラインになる前に自分のコミットメントトランザクションをネットワークにブロードキャストすることができます。 このコミットメントトランザクションの手数料率が即時承認されるには低すぎ、 アリスの取引相手（ボブ）が彼女のトランザクションを受け取っていない場合、 ボブは自分のコミットメントトランザクションをブロードキャストしても正常にリレーされないため、混乱するかもしれません。 各コミットメントトランザクションには、2つのアンカーアウトプットがあり、 どちらの参加者もコミットメントトランザクションをCPFPすることができます。 たとえば、ボブはアリスが以前コミットメントトランザクションをブロードキャストしているか確信を持てない場合でも、 アリスのコミットメントトランザクションのCPFPによる手数料の引き上げトランザクションを やみくもにブロードキャストしようとするかもしれません。 各アンカーアウトプットには、ダストの閾値を超える少額が割り当てられ、 UTXOセットの肥大化を防ぐために、しばらくすると誰でもそれを請求できるようになります。

しかし、各参加者がトランザクションをCPFPできることを保証することは、 各参加者にアンカーアウトプットを与えるよりも複雑です。 以前の記事で説明したように、Bitcoin Coreは DoS対策として未承認トランザクションにアタッチできる子孫トランザクションの数と合計サイズを制限しています。 各取引相手は、共有トランザクションに子孫をアタッチする能力を持っているため、 一方がこの制限を使い果たすことで、他方のCPFPトランザクションのリレーをブロックすることができます。 このような子孫の存在は、結果的にコミットメントトランザクションをmempool内で低優先度の状態に「固定」します。

この潜在的な攻撃を緩和するために、LNアンカーアウトプットの提案では、 すべてのアンカーアウト以外のアウトプットを相対的なタイムロックでロックし、 それらがトランザクションが未承認の間に使用されるのを防ぎます。 また、Bitcoin Coreの子孫制限ポリシーは、新しい子孫が小さく、他に祖先がない場合にのみ、 1つの追加の子孫を許可するよう変更されました（CPFP carve out）。 これら2つのプロトコルの変更の組み合わせにより、トランザクションリレーのDoS攻撃面を大幅に増加させることなく、 共有トランザクションの少なくとも2人の参加者がブロードキャスト時に手数料率の調整を行うことができるようになりました。

子孫制限の支配によるCPFPの防止は、Pinning攻撃の一例です。 Pinning攻撃は、mempoolポリシーの制限を利用して、インセンティブに適合するトランザクションが mempoolに入ったり承認されるのを阻止します。この場合、mempoolポリシーは、 DoS耐性とインセンティブ適合性の間のトレードオフを行っています。 ノードは手数料の引き上げを考慮すべきですが、無制限に多くの子孫を処理することはできません。 CPFP carve outは、特定のユースケースのためにこのトレードオフを洗練させています。

子孫制限を使い果たす以外にも、RBFの使用を完全に阻止したり、 RBFを法外に高価にしたり、RBFを活用してANYONECANPAYトランザクションの承認を遅らせたりするPinning攻撃があります。 Pinningが問題になるのは、複数の参加者が共同でトランザクションを作成するシナリオや、 信頼できない参加者がトランザクションとやりとりする余地がある場合のみです。 一般的に、信頼できない参加者へのトランザクションの露出を最小限に抑えることが、Pinningを回避する良い方法です。

これらの摩擦点は、Bitcoinエコシステムにおけるアプリケーションとプロトコルのインターフェースとしてポリシーの重要性だけでなく、 改善が必要な部分を浮き彫りにしています。来週の記事では、ポリシーの提案と未解決の問題について説明します。

リリースとリリース候補

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

  • ● Core Lightning 23.05.2は、この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 #24914は、依存関係を検出するためにデータベース全体を２回反復する代わりに、 ウォレットデータベースのレコードをタイプ毎に順番に読み込むようになりました。 レコードが破損している一部のウォレットは、この変更後に読み込めなくなる可能性がありますが、 前のバージョンのBitcoin Coreで読み込み、新しいウォレットに移植することができます。

  • ● Bitcoin Core #27896は、実験的なシステムコール（syscall）の サンドボックス機能（ニュースレター #170参照）を削除しました。 関連する課題とその後のコメントでは、 （syscallのホワイトリストとOSサポートの両方の）保守性や、 より適切にサポートされている代替手段、syscallのサンドボックス化がBitcoin Coreの責任であるかどうかに関する考慮事項など、 この機能の欠点が指摘されています。

  • ● Core Lightning #6334は、 アンカーアウトプットに対するCLNの実験的なサポートを更新および拡張しています（ CLNの初期実装については、ニュースレター #111参照）。 このPRの更新内容には、手数料ゼロのHTLCアンカーの実験的なサポートの有効化や、 ノードがアンカーチャネルの運用に必要な最低限の緊急資金を持っていることを確認するための設定可能なチェックを追加することなどが含まれています。

  • ● BIPs #1452は、ウォレットラベルのエクスポートフォーマットに関するBIP329仕様を更新し、 関連するアウトプットがウォレットで使用可能であるかどうかを示す新しいオプションのspendableタグを追加しました。 多くのウォレットは、コイン制御 機能を実装しており、ユーザーがプライバシーを損なう可能性のあるアウトプットなど、 特定のアウトプットを使用しないようにコイン選択アルゴリズムに指示することができます。

  • ● BIPs #1354は、ニュースレター #211に掲載した 複数の導出パスのディスクリプターに関するBIP389を追加しました。 これは、1つのディスクリプターで、HD鍵生成のための2つの関連するBIP32パス（最初のパスは支払いの受け取り用、 2つめのパスは内部ウォレットの支払い用（お釣りなど））を指定できるようにするものです。