今週のニュースレターでは、チャネル・ファクトリーとの互換性を改善する可能性のあるLNの修正バージョンの提案と、 LNプロトコルを変更することなくチャネルジャミング攻撃のいくつかの影響を軽減するソフトウェア、 シグナルのないトランザクションの置換を追跡するためのウェブサイトのリンクを掲載しています。 また、新しいクライントとサービスソフトウェアの発表や、 Bitcoin Stack Exchangeの人気のある質問とその回答、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● ファクトリーに最適化したLNプロトコルの提案: John Lawは、 チャネル・ファクトリーの作成に最適化したプロトコルの説明を Lightning-Devメーリングリストに投稿しました。 チャネル・ファクトリーでは、複数のユーザーが1つのオンチェーントランザクションのみで、 ユーザーのペア間の複数のチャネルをトラストレスに開設することができます。 たとえば、20人のユーザーが協力し、通常の2者間のチャネル開設の約10倍の規模のオンチェーントランザクションを作成して、 合計190個のチャネルを開設することができます。

    Lawは、（通常LNペナルティと呼ばれる）既存のLNチャネルプロトコルは、 ファクトリー内で開設されたチャネルについて2つの問題を生じさせると指摘しています:

    • ● HTLCの有効期限の長期化: トラストレスであるためには、 ファクトリー内の参加者がファクトリーから退出し、オンチェーンで自身の資金について独占的に管理できるようにする必要があります。 これは、参加者がファクトリー内の現在の残高の状態をオンチェーンに公開することで実現されます。 しかし、参加者が以前の状態（たとえば自分がより多くの資金を管理していた状態）を公開するのを防ぐ仕組みが必要です。 オリジナルのファクトリーの提案では、1つ以上のタイムロックされたトランザクションを使用することで、 古い状態よりも最新の状態をより迅速に承認できるようにします。

      この結果、Lawが説明したように、チャネル・ファクトリー内のチャネルを経由したLN支払い（HTLC）は、 ファクトリーが一方的に閉鎖できるように、最新の状態のタイムロックが失効するのに十分な時間を提供する必要があります。 さらにまずいことに、これは支払いがファクトリーを介して転送されるたびに適用されます。 たとえば支払いが、それぞれ1日の有効期限を持つ10個のファクトリーを経由して転送される場合、 支払いが偶然もしくは意図的に10日間（他のHTLCの設定によってはそれ以上）妨害される可能性があります。

    • ● オール・オア・ナッシング : ファクトリーが本当に最高の効率を達成するためには、 ファクトリー内のすべてのチャネルが、協力して単一のオンチェーントランザクションでクローズされる必要があります。 参加者のいずれかが応答しなくなった場合、協調クローズは不可能です。 参加者の数が増えるにつれ、参加者が応答しなくなる確率は100％に近づき、ファクトリーが提供できる最大のメリットは制限されます。

      Lawは、OP_TAPLEAF_UPDATE_VERIFYやOP_EVICTの提案（ニュースレター#166および#189参照） のように、参加者の1人が退出したい場合もしくは応答がない場合でもファクトリーの運用を継続できるようにする以前の研究を引用しています。

    この懸念事項に対処するため、Lawは3つのプロトコルを提案しています。 いずれも10月にLawが投稿した調整可能なペナルティ（執行の仕組み（ペナルティ）の管理を他の資金の管理から分離する機能）の提案に由来するものです。 この以前の提案は、Lightning-Devメーリングリストでまだ議論されていません。 この記事を書いている時点では、Lawの新しい提案もまだ議論されていません。 この提案が健全であれば、Bitcoinのコンセンサスルールを変更する必要がないという他の提案よりもメリットがあります。

  • ● リモートジャミングを防ぐためのローカルジャミング: Joost Jagerは、Lightning-Devメーリングリストに彼のプロジェクトであるCircuitBreakerのリンクと説明を投稿しました。 このプログラムはLNDと互換性を持つように設計されており、ローカルノードが各ピアに転送する保留中の支払い（HTLC）の数の制限を強制します。 たとえば、最悪の場合のHTLCのジャミング攻撃を考えてみましょう:

    2種類のジャミング個劇の図解

    現在のLNプロトコルでは、アリスは基本的に同時に転送可能な保留中のHTLCの数を最大483個に制限しています。 アリスが代わりにCircuitBreakerを使用すると、マロリーとのチャネルの同時保留HTLCを10個に制限し、 （図示されていない）ボブとの下流チャネルや他のチャネルは、マロリーが保留している10個のHTLCを除くすべてから保護されます。 これにより、マロリーは同じ数のHTLCスロットをブロックするのにさらに多くのチャネルを開く必要があるため、 マロリーの攻撃の有効性が著しく低下する可能性があり、さらにより多くのオンチェーン手数料を支払う必要があるため攻撃コストも増加します。

    CircuitBreakerはもともと上限を超えたチャネルのHTLCの受け入れを単に拒否するだけの実装でしたが、 Jagerは最近オプションで追加モードを実装し、HTLCをすぐに転送したり拒否するのではなく、 キューに入れるようにしたと述べています。あるチャネルの同時保留中のHTLCの数がチャネルの制限を下回ると、 CircuitBreakerはキューから最も古い有効期限の切れていないHTLCを転送します。 Jagerはこのアプローチの2つの利点を説明しています:

    • ● バックプレッシャー: 経路の途中にあるノードがHTLCを拒否した場合、 経路内のすべてのノード（下流ノードだけでなく）は、そのHTLCのスロットと資金を別の支払いの転送に使用することができます。 つまり、アリスがマロリーから10を超えるHTLCを拒否するインセンティブは限定されてます。 アリスは経路内の後のノードでCircuitBreakerまたは同等のソフトウェアが実行されるのを期待するだけです。

      しかし、後のノード（ボブとします）がCircuitBreakerを使って制限を超えるHTLCをキューに入れると、 ボブや経路内のそれ以降のノードにとっては現在と同じ利点があったとしても、 アリスは自身のスロットまたは資金をマロリーによって枯渇させられる可能性があります （ただし、場合によってはボブのチャネルクローズコストが増加する可能性があります。 詳細はJagerのメールやCircuitBreakerのドキュメントを参照ください）。 これはアリスにCircuitBreakerや同等のソフトウェアを実行することを穏やかに迫ります。

    • ● 失敗の原因: 現在のLNプロトコルでは、（多くの場合）支払人はHTLCの転送を拒否したチャネルを特定できます。 一部のソフトウェアは、将来のHTLCでこれらのチャネルを一定期間使用しないようにします。 マロリーのような悪意あるユーザーからのHTLCを拒否する場合、これは問題ではありませんが、 ノードがCircuitBreakerを実行し正直な支払人からのHTLCを拒否した場合、 拒否したHTLCによる収益が減るだけでなく、その後の支払いの試行から受け取る可能性のあった収益も減少する可能性があります。

      ただし、現在のLNプロトコルにはどのチャネルがHTLCを遅延させたかを判断する広く展開された方法がないため、 この点については、HTLCの転送を完全に拒否するよりも遅延させた方が影響は少なくなります。 Jagerは、多くのLN実装がより詳細なオニオンルーティングされたエラーメッセージ（ニュースレター #224参照） のサポートに取り組んでいるため、この利点がいつか消えるかもしれないと指摘しています。

    JagerはCircuitBreakerを「チャネルジャミングやスパムに対処するための単純だが不完全な方法」としています。 ジャミング攻撃に関する懸念をより包括的に軽減するプロトコルレベルの変更を発見して展開する研究は続いていますが、 CircuitBreakerは現在のLNプロトコルと互換性があり、LNDのユーザーが自分の転送ノードにすぐに展開できるという、 一見妥当な解決策として際立っています。CircuitBreakerはMITライセンスで、概念的にシンプルなので、 他のLN実装への適用や移植も可能なはずです。

  • ● フルRBF置換のモニタリング: 開発者の0xB10Cは、 BIP125のシグナルを含まないBitcoin Coreノードのmempool内のトランザクションの置換について 一般にアクセス可能なモニタリングの提供を開始したことをBitcoin-Devメーリングリストに投稿しました。 これらのBitcoin Coreのノードは、mempoolfullrbf設定オプションを使用してフルRBFを可能にします（ニュースレター #208参照）。

    ユーザーやサービスは、どの大規模マイニングプールが現在シグナルのない置換トランザクションを承認しているか（承認している場合は）の 指標としてウェブサイトを使用できます。ただし、マイナーが現在シグナルのない置換をマイニングしていないように見えても、 未承認トランザクションで受け取った支払いは保証できないことを覚えておいてください。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● Lily Walletがコイン選択機能を追加: Lily Wallet v1.2.0は、コイン選択機能を追加しました。

  • ● VortexソフトウェアがCoinJoinからLNチャネルを作成: Taprootと共同CoinJoinトランザクションを使用して、 ユーザーはVortexソフトウェアを使用してBitcoinのmainnet上でLNチャネルを開設しました。

  • ● MutinyがブラウザでのLNノードのPoC: 開発者は、WASMとLDKを使用して、携帯電話のブラウザで動作するLNノードの実装の概念実証をデモしました。

  • ● CoinkiteがBinaryWatch.orgをローンチ: BinaryWatch.orgは、Bitcoin関連のプロジェクトのバイナリをチェックし、 変更されていないかチェックするウェブサイトです。 また、Bitcoin関連のプロジェクトの再現可能なビルドをアーカイブするサービス bitcoinbinary.orgも運営しています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • ● Bitcoin Core 24.0.1は、最も広く利用されているフルノードソフトウェアのメジャーリリースです。 その新機能には、ノードのRBF（Replace-By-Fee）ポリシーを設定するオプションや、 単一のトランザクションでウォレットの資金をすべて簡単に使用するため （またはお釣りのアウトプットのないトランザクションを作成するため）の新しいsendallRPC、 トランザクションがウォレットに与える影響を検証するために（たとえば、 CoinJoinトランザクションが手数料によってウォレットの金額を減少させるだけであること確認するなど） 使用できるsimulaterawtransactionRPC、 他のソフトウェアとの互換性を高めるためにMiniscriptの式を含む 監視専用のディスクリプターを作成する機能、 GUIで行った特定の設定変更をRPCベースのアクションに自動適用する機能などが含まれています。 新しい機能とバグ修正の完全なリストについては、リリースノートをご覧ください。

    注意：バージョン24.0はタグ付けされバイナリがリリースされましたが、 プロジェクトのメンテナーはそれを発表せず、他のコントリビューターとともに、 直前に見つかった問題を解決したため、 この24.0.1のリリースが24.xブランチの最初に発表されたリリースになりました。

  • ● libsecp256k1 0.2.0は、Bitcoin関連の暗号処理に広く使用されているこのライブラリの最初のタグ付きリリースです。 このリリースの発表では、 「長い間、libsecp256k1の開発にはmasterブランチしかなく、 APIの互換性と安定性に関して不明確な点がありました。 今後は関連する改良がマージされた際にタグ付きのリリースを作成し、 セマンティックバージョニング方式に従います。[…] バージョン0.1.0は、何年も前からautotoolsのビルドスクリプトで設定されていたバージョン番号で、 ソースファイルのセットを一意に識別できないため、スキップすることにしました。 バイナリリリースは作成しませんが、予想されるABI互換の問題を考慮して、 リリースノートとバージョニングを作成する予定です。」

  • ● Core Lightning 22.11.1は、一部の開発者からの要望で、 22.11で非推奨となった機能を一時的に再導入するマイナーリリースです。

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

今週のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、およびLightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #25934は、listsinceblockRPCにオプションのlabel引数を追加しました。 labelが指定された場合、それにマッチするトランザクションのみが返されます。

  • ● LND #7159は、ListInvoiceRequestRPCとListPaymentsRequestRPCに 新しいcreation_date_startフィールドとcreation_date_endフィールドを追加し、 指定した日時の前か後のインボイスと支払いのフィルタリングに使用できるようにしました。

  • ● LDK #1835は、インターセプトしたHTLCに対して偽のSCID（Short Channel IDentifier）名前空間を追加し、 LSP（Lightning Service Provider）がエンドユーザーに対して、 ライトニング支払いを受けるためのJIT（just-in-time）チャネルを作成できるようにします。 これはエンドユーザーのインボイスに偽のルートヒントを含めることで、 ファントム・ペイメントと同様に、 インターセプト転送であることをLDKに通知します（ニュースレター #188参照）。 LDKはその後イベントを発生させ、LSPにJITチャネルを開く機会を与えます。 LSPは、新しく開設したチャネルで支払いを転送するか、失敗させることができます。

  • ● BOLTs #1021は、オニオンルーティングのエラーメッセージにTLVストリームを含めることができるようにしました。 これは、将来、障害に関する追加情報を含めるために使用される可能性があります。 これは、BOLTs #1044で提案されたように、ファット・エラーを実装するための最初のステップです。

ハッピーホリデー！

これは、Bitcoin Optechの今年最後の定期ニュースレターとなります。 12月21日（水）には、5回目の年間の振り返り特別号を発行します。 通常の発行は、1月4日（水）から再開します。