今週のニュースレターでは、モバイルウォレットが追加のUTXOなしでLNチャネルを決済できるようにするためのアイディアと、 LNの経路探索用にサービス品質フラグを追加することに関する議論の続きの要約を掲載しています。 また、クライアント、サービスおよび人気のBitcoinインフラストラクチャソフトウェアの最近の変更など 恒例のセクションも含まれています。

ニュース

  • ● モバイルウォレットが追加のUTXOなしでチャネルを決済できるようにする: Bastien Teinturierは、盗難の可能性があるすべてのケースで、 モバイルウォレットがチャネル内の資金を使ってチャネルを決済できるようにする、 LNチャネル用のv3コミットメントのオプトイン版について Delving Bitcoinに投稿しました。 モバイルウォレットは、チャネルを閉じるための手数料を支払うためにオンチェーンUTXOを準備しておく必要がなくなります。

    Teinturierまず、モバイルウォレットがトランザクションをブロードキャストする必要がある 4つのケースの概要を説明しています:

    1. ピアが失効したコミットメントトランザクションをブロードキャストする、つまり、 ピアが資金を盗もうとしている場合です。 この場合、モバイルウォレットはすぐにチャネルの資金をすべて使用できるようになり、 その資金を使って手数料を支払うことができます。

    2. モバイルウォレットがまだ決済されていない支払いを送信した場合。 この場合、窃盗は不可能で、リモートピアはHTLCプリイメージ （つまり、最終的な受取人が支払いを受けたという証拠）を提供することによってのみ支払いを請求できます。 窃盗は不可能なので、モバイルウォレットはチャネルを閉じるための手数料を支払うために必要なUTXOを時間をかけて用意することができます。

    3. 保留中の支払いがなくリモートピアが応答しない場合。 この場合も窃盗は不可能なので、モバイルウォレットは時間をかけてチャネルを閉じることができます。

    4. モバイルウォレットがHTLCを受信している場合。この場合、 リモートピアはHTLCプリイメージを受け入れることができます（これにより、 上流のピアに資金を請求できます）が、決済されたチャネル残高を更新してHTLCを取り消すことはできません。 この場合、モバイルウォレットは比較的少数のブロック内でチャネルを強制的に閉じる必要があります。 これが、この記事の残りで取り扱うケースです。

    Teinturierは、リモートピアがモバイルウォレットに支払う各HTLCの2つの異なるバージョンに署名することを提案しています。 1つは手数料ゼロのコミットメントに対するデフォルトポリシーに従う手数料ゼロバージョンで、 もう1つは現在すぐに承認される手数料率で手数料を支払うバージョンです。 手数料はモバイルウォレットに支払われるHTLCから差し引かれるため、 このオプションを提供するリモートピアにコストはかからず、 モバイルウォレットには本当に必要な場合にのみこのオプションを使用するインセンティブが生まれます。 Teinturierは、リモートピアが手数料を支払い過ぎると安全上の考慮事項がいくつかあると 指摘していますが、それらは簡単に対処できるだろうと予想しています。

  • ● LNのサービス品質フラグに関する議論の続き: Joost Jagerは、 LNプロトコルにサービス品質（QoS）フラグを追加して、 ノードが彼らチャネルの1つが高可用性（HA）である（つまり、指定された金額まで100%の信頼性で支払いを転送できる）ことを 通知できるようにすること（ニュースレター #239参照）についての議論の続きをDelving Bitcoinに投稿しました。 支払人がHAチャネルを選択し、そのチャネルで支払いが失敗した場合、 支払人はそのチャネルを二度と使用しないことでオペレーターにペナルティを課します。 以前の議論から、Jagerはノードレベルのシグナリング（おそらく、 ノードのテキストエイリアスに「HA」を追加するだけ）を提案し、 プロトコルの現在のエラーメッセージでは支払いが失敗したチャネルの検出が保証されないことを指摘し、 これは完全にオプトインベースでシグナリングと使用の両方ができるものではないため（つまり、広範な合意を必要としないので）、 最終的にそれを使用する支払いノードと転送ノードがほとんどいないとしても、 互換性のために規定されるべきだと提案しました。

    Matt Coralloは、LNの経路探索は現在うまく機能していると答え、 LDKの経路探索アプローチを説明する詳細なドキュメントのリンクを貼りました。 このアプローチは、René PickhardtとStefan Richterが最初に説明したアプローチ（ ニュースレター #163およびニュースレター #270の 2つの項目を参照）を拡張したものです。ただし、 QoSフラグによって将来のソフトウェアが信頼性の低い経路探索を実装し、 HAチャネルのみの使用を優先するのではないかと懸念しています。その場合、 大規模なノードは、チャネルが枯渇した際に一時的に信頼ベースの流動性を使用するという合意を大規模ピアと締結できますが、 トラストレスなチャネルに依存する小規模ノードは、コストのかかるJITリバランスを使用する必要があり、 （コストを吸収する場合）チャネルの収益性が低下するか、 （コストを支払人に転嫁する場合）望ましくない形になります。

    JagerとCoralloは、議論を続けましたが、明確な解決策には至りませんでした。

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

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

  • ● Ark Wallet SDKのリリース: Ark Wallet SDKは、testnet、signet、 Mutinynetおよびmainnet（現在は非推奨）でオンチェーンのBitcoinと Arkの両方をサポートするウォレットを構築するためのTypeScriptライブラリです。

  • ● ZapriteがBTCPay Serverをサポート: Bitcoinおよびライトニング決済インテグレーターのZapriteは、 サポートするウォレット接続リストにBTCPay Serverを追加しました。

  • ● Iris Walletデスクトップリリース: Iris Walletは、RGBプロトコルを使用した アセットの発行、送信、受信をサポートします。

  • ● Sparrow 2.1.0リリース: Sparrow 2.1.0リリースでは、以前のHWI実装がLarkに置き換えられ、 PSBTv2のサポートとさまざまな更新が行われています。

  • ● Scure-btc-signer 1.6.0リリース: Scure-btc-signerの1.6.0リリースでは、 バージョン3（TRUC）トランザクションおよび P2A（pay-to-anchors）がサポートされました。 Scure-btc-signerは、scureライブラリスイートの一部です。

  • ● Py-bitcoinkernelアルファ: Py-bitcoinkernelは、 Bitcoin Coreの検証ロジックをカプセル化するライブラリである libbitcoinkernelと対話するためのPythonライブラリです。

  • ● Rust-bitcoinkernelライブラリ: Rust-bitcoinkernelは、libbitcoinkernelを使用してブロックデータを読み取り、 トランザクションアウトプットとブロックを検証するための実験的なRustライブラリです。

  • ● BIP32 cbip32ライブラリ: cbip32ライブラリは、libsecp256k1とlibsodiumを使用して CでBIP32を実装しています。

  • ● Lightning LoopがMuSig2に移行: Lightning Loopのスワップサービスは、最近のブログ記事で説明されているように、 MuSig2を使用するようになりました。

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

今週の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 #27432では、dumptxoutset RPCコマンドで生成された コンパクトにシリアライズされたUTXOセット（AssumeUTXOスナップショット用に設計）を SQLite3データベースに変換するPythonスクリプトが導入されています。dumptxoutset RPC自体を拡張してSQLite3データベースを出力することも検討されましたが、 メンテナンスの負担が増すため、最終的に却下されました。 このスクリプトは追加の依存関係を必要とせず、結果のデータベースはコンパクトにシリアライズされたUTXOセットの約2倍のサイズになります。

  • ● Bitcoin Core #30529では、noseednode、nobind、nowhitebind、norpcbind、 norpcallowip、norpcwhitelist、notest、noasmap、norpcwallet、noonlynet、 noexternalipなどの否定オプションの処理が修正され、期待どおりに動作します。 これまでは、これらのオプションを否定すると、混乱を招き、文書化されていない副作用が発生していましたが、 現在は指定された設定をクリアしてデフォルトの動作を復元するだけです。

  • ● Bitcoin Core #31384は、ブロックヘッダー、トランザクション数、コインベーストランザクション用に予約された 4,000 WU（weight unit）が誤って2回適用され、最大ブロックテンプレートのサイズが、 不要に4,000 WU削減されて3,992,000 WUになる問題（ニュースレター#336参照）を解決します。 この修正により、予約されたweightが1つのインスタンスに統合され、 ユーザーが予約されるweightをカスタマイズできる新しい-blockreservedweight起動オプションが導入されます。 予約されるweightが2,000 WUから4,000,000 WUの間の値に設定されていることを保証するための安全性チェックも追加されています。 この範囲外の場合、Bitcoin Coreは起動に失敗します。

  • ● Core Lightning #8059は、xpayプラグイン（ニュースレター#330参照）において、 マルチパス支払い（MPP）をサポートしていないBOLT11インボイスに支払いをする際に、 この機能を抑制する機能を実装しました。同じロジックがBOLT12インボイスにも拡張される予定ですが、 次のリリースまで待たなければなりません。このPRで、BOLT12機能をプラグインに通知できるようにし、 BOLT12インボイスをMPPで支払うことを明示的に許可するからです。

  • ● Core Lightning #7985は、ブラインドパス経由のルーティングを有効にし、 renepayの内部で使用されていたsendpayRPCコマンドをsendonionに置き換えることで、 renepayプラグイン（ニュースレター#263参照）で BOLT12インボイスへの支払いをサポートできるようになりました。

  • ● Core Lightning #7887は、最新のBOLTの更新（ニュースレター#290および #333参照）に準拠するために、 HRN（Human Readable Name）解決用の新しいBIP353フィールドの処理をサポートします。 このPRではまた、インボイスにinvreq_bip_353_nameフィールドを追加し、 受信BIP353名フィールドの制限を適用し、ユーザーがfetchinvoice RPCでBIP353名を指定できるようにし、 文言も変更しました。

  • ● Eclair #2967は、BOLTs #1205で定義されているoption_simple_closeプロトコルをサポートします。 この協調クローズプロトコルの簡略化版は、Simple Taproot Channelの前提条件です。これによりノードは、shutdown、closing_complete、closing_sig フェーズ中にnonceを安全に交換できます。これは、MuSig2チャネルアウトプットを使用するために必要です。

  • ● Eclair #2979は、トランポリン支払いを中継するための ウェイクアップフローを開始する前に、ノードがウェイクアップ通知（ニュースレター#319参照 ）をサポートしていることを確認する検証手順を追加します。標準のチャネル支払いの場合、 BOLT11またはBOLT12インボイスでウェイクアップ通知のサポートが既に示されているため、 このチェックは不要です。

  • ● Eclair #3002は、セキュリティを強化するために、ブロックとその承認済みトランザクションを処理して 監視をトリガーするセカンダリの仕組みを導入します。これは、チャネルが使用されたか、 支払いトランザクションがmempoolで検知されていない場合に特に便利です。 ZMQのrawtxトピックはこれを処理しますが、信頼性が低く、 リモートのbitcoindインスタンスを使用する場合に密かにドロップする可能性があります。 新しいブロックが見つかるたびに、セカンダリシステムは最新Nブロック（デフォルトで6）を取得し、 そのトランザクションを再処理します。

  • ● LDK #3575は、ノードがチャネルピアのバックアップを配布および保存できるようにする機能として ピアストレージプロトコルを実装します。ノード間でこれらのバックアップを交換できるように、 2つの新しいメッセージタイプ、PeerStorageMessageとPeerStorageRetrievalMessageと それぞれのハンドラーが導入されています。ピアのデータは、ChannelManagerのPeerState内に永続的に保管されます。

  • ● LDK #3562は、外部ソースからの実際の支払いパスの頻繁なプローブに基づいて スコアリングベンチマークをマージする新しいスコアラー（ニュースレター#308参照）を導入します。 これにより、一般的にネットワークビューが制限されている軽量ノードは、 LSP（Lightning Service Provider）によって提供されるスコアなどの外部データを組み込むことで、 支払いの成功率を向上させることができます。外部スコアは、ローカルスコアと組み合わせることも、 ローカルスコアを上書きすることもできます。

  • ● BOLTs #1205は、Simple Taproot Channelに必要な 協調クローズプロトコルの簡略化版であるoption_simple_closeプロトコルをマージします。 BOLT2とBOLT3が変更されました。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 （ニュース レターが公開された翌日の）木曜日の17:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議 論は録画もされ、ポッドキャストページからご覧いただけます。