今週のニュースレターでは、オフラインのLNノードがオンチェーンで資金を受け取り、 後で余計な遅延なくオフチェーンで使用できるようにするためのアイディアを掲載しています。 また、新しいソフトウェアリリースとリリース候補の概要や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

• ● 非対話型のLNチャネル開設コミットメント: 開発者のZmnSCPxjとJesse Posnerは、 Swap-in-Potentiamという、LNチャネルを開設するための新しい手法の提案を Lightning-Devメーリングリストに投稿しました。 既存のLNチャネルの開設方法では、チャネルに資金をデポジットする前に、 各参加者が払い戻しのトランザクションに署名する必要があります。 払い戻しのトランザクションを作成するには資金の詳細を知る必要があるため、 既存のLNチャネルの開設手法では、資金提供者が相手に提供予定の資金の情報を伝え、 相手が払い戻しトランザクションを作成、署名し、 その後資金提供者がファンディング・トランザクションに署名して送信するという対話が必要になります。

  著者らは、これは一部のウォレット、特にオフラインのウォレットや、 常時動作できない可能性のあるモバイルデバイスのウォレットにとって問題であると指摘しています。 このようなウォレットに対しては、LNノードが到達できない場合に、 資金を受け取ることができるフォールバック用のオンチェーンアドレスを生成するのが合理的です。 ウォレットが次にオンラインになった際に、オンチェーンの資金を使用してLNチャネルを開設することができます。 ただし、新しいLNチャネルは、非資金提供者が安全かつトラストレスに資金提供者のために支払いを転送する前に、 妥当な深さまで（たとえば、6承認）承認される必要があります。 つまり、ノードがオフラインの際に支払いを受けたモバイルウォレットのユーザーは、 LN上でそのお金を新しい支払いに使用するまで、オンラインになってから6ブロック待つ必要がある可能性があるということです。

  著者らは、代替案を提案しています：ユーザーであるアリスは、 常時利用可能なノード（たとえば、LSP、Lightning Service Provider）を持つ取引相手（ボブ）を事前に選択します。 アリスとボブは協力して、たとえばアリスの署名に加えて、 ボブの署名か数週間のタイムロック（たとえば6,000ブロック）の期限が切れれば 使用可能にするスクリプトのオンチェーンアドレスを作成します。 例:

    pk(A) && (pk(B) || older(6000))
  

  このアドレスで、アリスはオフラインの間に承認が始まる支払いを受け取ることができます。 支払いが有効な承認数を得るまでは、ボブはその資金を使用しようとする試みに対して共同で署名するする必要があります。 ボブが、アリスが署名した単一の支払いの試行にしか署名しないことを選択すると、 ボブはアリスが有効期限前にそのお金を二重使用することができないことを確信できます。 アリスによる支払いが無効になる唯一の方法は、アリスへのそれ以前の支払いも二重使用される場合です。 もしその支払いが、アリスがオンラインになって支払いを始める前に既に何度も承認されていれば、 二重使用は起こり得ないはずです。

  このため、アリスは自分のウォレットがオフラインのときに支払いを受け取ることができ、 その支払いが少なくとも6回承認された後（しかし6,000承認よりかなり少ない）、 オンラインになり、LNチャネルを開くためにすぐにトランザクションに共同署名することができます。 ボブはこのチャネルの資金が二重使用できないことを知っています。 チャネル作成のトランザクションが承認される前でも、 ボブはアリスのために安全かつトラストレスに支払いの転送を始めることができます。 もしくは、アリスとボブの両者が既にLNチャネルを持っている場合（お互いに、または別のピアと）、 ボブはアリスにLN支払いを送ることができ、アリスはオンチェーン資金を使用することでそれを入手できます。 あるいは、アリスのウォレットがオンラインになり、アリスは通常のオンチェーン支払いをしたいと判断した場合、 必要なのはボブのウォレットが支払いに対して共同で署名するだけです。ワーストケースとして、 ボブが非協力的になった場合、アリスは数週間待つだけでボブの協力なしに資金を使用することができるようになります。

  オフラインのウォレットがLNの資金を受け取れるようにするだけでなく、 このアイディアを非同期支払いと上手く組み合わせて、 オフラインのクライアントがオンラインに戻った際に、LSPがチャネルのリバランス操作を事前に準備し、 ユーザー視点で遅延なくそのリバランス操作を実行できるようにする方法も説明しています。 たとえば、キャロルがアリスのチャネルの現在のキャパシティより大きい金額の非同期支払いをアリスに送信した場合、 ボブはスクリプトpk(B) && (pk(A) || older(6000))に支払いを送信することができます。 この代替スクリプトは、アリスとボブの役割を反転させています。 アリスが次にオンラインになるまで、ボブの支払いが十分な数の承認を得た場合、 アリスは直ちにその支払いを新しいLNチャネルにアップグレードし、 ボブにその新しいチャネルで非同期支払いを転送してもらい、LNの通常の安全でトラストレスな特性を維持します。

  このアイディアに対して、この記事を書いている時点で、メーリングリスト上でそれなりの量の議論がありました。 アイディアの側面について明確化を求めるコメントがいくつかと、 一般的なコンセプトを強く支持するコメントが少なくとも１つありました。

リリースとリリース候補

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

• ● BDK 0.26.0は、ウォレット構築用のこのライブラリの新しいリリースです。

• ● HWI 2.2.0-rc1は、ソフトウェアウォレットとハードウェア署名デバイスのインターフェースとなる、 このアプリケーションのリリース候補です。

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

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

• ● Eclair #2455は、BOLT 04に最近導入されたonion failureメッセージの オプションTLV（Type-Length-Value）ストリームのサポートを実装しました。 TLVストリームは、ノードがルーティングの障害について追加の詳細情報を報告できるようにし、 エラー特定のギャップをさらに縮めるために提案されたファットエラー方式に使用されるかもしれません。