今週のニュースレターでは、オフチェーン支払いの新しい解決プロトコルと、 LN支払いの潜在的なIP層の追跡と検閲に関する論文のリンクを掲載しています。また、 新しいリリースとリリース候補の発表や（BTCPay Serverのセキュリティ上の重要な更新を含む）、 人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更の説明も含まれています。

ニュース

• ● MADベースのオフチェーン支払いの解決（OPR）プロトコル: John Lawは、参加者双方が資金を債権に拠出することを要求するマイクロペイメントプロトコルの説明を Delving Bitcoinに投稿しました。この債権は、どちらの参加者によっても いつでも事実上破壊することができます。これにより両者に、相手をなだめるか、 債権の相互確証破壊（MAD）のリスクを負うかのインセンティブが生まれます。

  これは、プロトコル違反が起きた場合に、その責任のある参加者のみが資金を失うという トラストレスプロトコル との理想とは異なります。ただし、実際には、 LNなどに導入されたトラストレスプロトコルでは、違反により資金を回収するために、 プロトコルに準拠している参加者がオンチェーン手数料を支払う必要があることがよくあります。 Lawはこの事実を利用して、MADベースのプロトコルの利点をいくつか主張しています:

  • 資金が破棄された場合、トラストレスなコントラクトの強制よりもブロックチェーンのスペースがはるかに少なく、 スケーラビリティが向上します。

  • グローバルなコンセンサスではなく、取引相手との宥和に基づいているため、 すくなくとも数ブロックという最小値ではなく、ほんの一瞬の短い有効期限を強制できます。 Lawは、現在LNが支払いを決済するのに最悪の場合、最大2週間を要するのに対し、 10秒未満で支払いの解決（成功または失敗）が保証される例を挙げています。

  • 2つの取引相手間で、通信障害が長期化した場合、MADベースのプロトコルでは、 どちらの参加者もデータをオンチェーンに展開する必要はありません（そして、 債権の保証金の一部を失うことになるため、どちらの参加者もそのようなことをしないインセンティブが働きます）。 LN-Penaltyのようなプロトコルでは、 チャネル内の保留中のHTLCを期限までにオンチェーンで決済しなければなりません。

    Lawは、チャネルファクトリーやタイムアウトツリー、 または理想的にはネストされた部分をオフチェーンに保持する他のネスト構造内で、 OPRをより効率的にすることができると強調しました。

  Matt Morehouseは、宥和策は論理的に盗難を遅らせることにつながると回答しました。 たとえば、マロリーはボブが債権の5%に相当する操作を失敗したと主張します。 ボブは自分が失敗したかどうかの確証がなかったものの、債権の50%を失うよりはましなのでマロリーに5%を支払うことに同意します。 マロリーはこれを繰り返します。この問題は、一般的な通信ネットワークでは障害を証明できないためさらに悪化します。 マロリーとボブが連絡が取れなくなり、障害が発生すると、お互いに相手を責め、MADが発生する可能性があります。 Morehouseはさらに、OPRでは債権の預託金のためにより多くのユーザー資金を確保する必要があり、 UXが低下する可能性があると指摘しています。現在のユーザーは、チャネル残高の99%以上は使用できないようにする BOLT2の チャネルリザーブ について既に混乱しています。

  この記事の執筆時点で、議論はまだ進行中でした。

• ● LN支払いのIP層の検閲に関する論文: Charmaine Ndoloは、 LN支払いのプライバシーの低下と検閲の可能性に関する最近の2つの論文の要約を Delving Bitcoinに投稿しました。論文では、 LNプロトコルのメッセージを含むTCP/IPパケットに関するメタデータ（パケット数やデータ総量など）により、 それらのメッセージに含まれるペイロードの種類（新しいHTLCなど）を推測することが 比較的容易であると指摘しています。複数のノードが使用するネットワークを制御する攻撃者は、 ノード間を移動するメッセージを観察できる可能性があります。 攻撃者がそれらのLNノードの１つも制御している場合、送信されているメッセージに関する情報（支払い金額や それがOnionメッセージであることなど）が分かります。 これを利用することで、一部の支払いを選択的に成功しないようにしたり、 すぐに失敗させないようにすることで即座に再試行するのを防ぎ、 チャネルをオンチェーンで強制的に閉鎖させる可能性があります。

  この記事の執筆時点では、返信は投稿されていませんでした。

リリースとリリース候補

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

• ● BTCPay Server 2.0.3と1.13.7は、 特定のプラグインや機能のユーザーにとってセキュリティ上重要な修正を含むメンテナンスリリースです。 詳細については、リンクのリリースノートをご覧ください。

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

最近の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 #30592では、ユーザーがフルRBFを無効にしてオプトインRBFに戻すことができる mempoolfullrbf設定オプションを削除しました。フルRBFが広く採用されている現在、 無効にするメリットがないため、このオプションは削除されました。 フルRBFは最近デフォルトで有効になりました（ニュースレター#315参照）。

• ● Bitcoin Core #30930では、netinfoコマンドにピアサービス列と、 送信接続のみを表示するoutonlyフィルターオプションが追加されました。 新しいピアサービス列には、各ピアでサポートされているサービスのリストが表示され、 フルブロックチェーンデータ (n)、ブルームフィルター (b)、 segwit (w)、コンパクトフィルター (c)、 最新288ブロックまでの限定ブロックチェーンデータ (l)、 バージョン2 P2Pトランスポートプロトコル (2)が含まれます。 ヘルプテキストもいくつか更新されています。

• ● LDK #3283では、BIP353を実装し、BLIP32で定義されている BOLT12オファーに解決するDNSのベースの人が読めるBitcoin支払い指示への支払いのサポートが追加されました。 新しいpay_for_offer_from_human_readable_nameメソッドがChannelManagerに追加され、 ユーザーはHRNへの支払いを直接開始できます。またこのPRでは、 保留中の解決を処理するためのAwaitingOfferペイメントステートと、 BLIP32クエリを処理するための新しいlightning-dns-resolverクレートも導入されています。 これに関する以前の作業については、ニュースレター#324をご覧ください。

• ● LND #7762は、コマンドが正常に実行されたことをより明確に示すために、 空の応答を返す代わりに、ステータスメッセージを返すようにいくつかのlncli RPCコマンドを更新しました。 影響を受けるコマンドには、wallet releaseoutput、wallet accounts import-pubkey、 wallet labeltx、sendcustom、connect、disconnect、stop、deletepayments、 abandonchannel、restorechanbackup、verifychanbackupが含まれます。