今週のニュースレターでは、Covenantを使用してLNのスケーラビリティを大幅に向上させる提案を掲載しています。 また、Bitcoin Stack Exchangeで人気の質問とその回答の要約や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● Covenantを使用したLNのスケーラビリティの向上: John Lawは、 Covenantを使用して非常に大規模なチャネル・ファクトリーを作成し、 これまでに説明したいくつかのプロトコル（ニュースレター#221、#230および#244参照） を適用してチャネルを管理する方法について執筆した論文の概要を Bitcoin-DevメーリングリストとLightning-Devメーリングリストに投稿しました。

    彼は、Coinjoinや以前のファクトリーの設計のように、 多数のユーザーの参加を必要とする署名ベースのプロトコルにおけるスケーラビリティの問題について説明しています。 たとえば、1,000人のユーザーがプロトコルへの参加に同意したものの、その内の1人が署名中に利用できなくなった場合、 他の999個の署名は役に立ちません。次の試行中に、別のユーザーが利用できなくなった場合、 2回めの試行で収集された他の998個の署名も役に立ちません。 彼は、この問題の解決策として、OP_CHECKTEMPLATEVERIFYや SIGHASH_ANYPREVOUTのようなCovenantを提案しています。 これらは、1つの小さなトランザクションが、 その資金を1つ以上の事前に定義された子トランザクションでのみ使用できるように制限できることで知られています。 その後のトランザクションもCovenantによって制限することができます。

    Lawは、この仕組みを使用して タイムアウトツリー を作成し、 ファンディング・トランザクション が事前に定義された子トランザクションのツリーに支払いをし、 それらが最終的にはオフチェーンで多数の個別のペイメントチャネルに支払われます。 Ark（ニュースレター #253参照）で使用されているものと同様の仕組みにより、 各ペイメントチャネルをオプションでオンチェーンにすることができますが、 ファクトリーの資金提供者は、有効期限後にオンチェーンに移されていないチャネル資金を回収することもできます。 これは非常に効率的です。1つの小さなオンチェーントランザクションを使用して、 何百万ものチャネルに資金を提供するオフチェーンのタイムアウトツリーを作成できます。 有効期限後、資金はファクトリーの資金提供者によって別の小さなオンチェーントランザクションで回収され、 個々のユーザーはファクトリーの有効期限が切れる前にLN経由で資金を他のチャネルに引き出すことができます。

    上記のモデルは、現在使用されているLN-Penaltyチャネルの構成と、 提案中のLN-Symmetryの仕組みと互換性があります。ただ、 Lawの論文の残りの部分では、Covenantベースのファクトリーの設計にいくつかの利点をもたらす、 彼が提案したFFO-WF（Fully Factory Optimized Watchtower Free）プロトコルの修正について検討しています。 以前のニュースレターで説明した、 カジュアルなユーザー は数ヶ月に数分間だけオンラインになることで済むことや、 熱心なユーザー はチャネルをまたいで資金をより効率的に使用できることなどの利点に加えて、 更新された構成の新たな利点により、ファクトリーの資金提供者は、 カジュアルユーザーの資金をある（特定のオンチェーントランザクションに基づく）ファクトリーから （別のオンチェーントランザクションでアンカリングされている）別のファクトリーに、 ユーザーとのやり取りなしで移動することができます。 つまり、ファクトリーの6ヶ月の有効期限が切れる前にオンラインになる必要があることを知っているカジュアルユーザーのアリスは、 5ヶ月めにオンラインになって、有効期限までさらに数ヶ月ある新しいファクトリーに彼女の資金が既にロールオーバーされていることに気づくかもしれません。 アリスは何もする必要はありません。彼女は自分の資金をトラストレスに完全に管理しています。 これにより、アリスが有効期限間近にオンラインになり、ファクトリーの資金提供者が一時的に利用できないことが分かり、 タイムアウトツリーの一部をオンチェーン化せざるを得なくなり、 トランザクション手数料が発生し、ネットワーク全体のスケーラビリティが低下するといった可能性を減らすことができます。

    Anthony Townsは、大規模な熱心なユーザーの故意または偶発的な障害により、 他の多くのユーザーが同時に多くの時間的制約のあるトランザクションをオンチェーン化する必要がある 「Thundering Herd」問題（LNのオリジナルの論文では 「forced expiration spam」と呼ばれている）について懸念を表明しました。 たとえば、100万人のユーザーがいるファクトリーでは、これらのユーザーが資金を新しいチャネルに戻すのに、 最大100万件のトランザクションの時間制限のある承認と、 さらに最大200万件のトランザクションの時間制限のない承認が必要になる場合があります。 現在、ネットワークが300万件のトランザクションを承認するのに約1週間かかるため、 100万人のユーザーを持つファクトリーのユーザーは、 有効期限が切れる数週間前にファクトリーに資金をオールオーバーしてもらいたいと望むかもしれません。 あるいは、いくつかの100万人規模のファクトリーで同時に問題が発生することを心配する場合、 数ヶ月前にロールオーバーすることを望むかもしれません。

    LNのオリジナルの論文では、「ブロックがいっぱい」の（たとえば、手数料率が通常の金額を超えている）場合に、 有効期限を遅らせるGregory Maxwellのアイディアを使って、 この問題に対処できる可能性があることを示唆しています。 LawはTownsへの返信の中で、その種の解決策の具体的な設計に取り組んでおり、 考えたまとまったら発表すると述べています。

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

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

リリースとリリース候補

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

  • ● LND v0.17.0-beta.rc5は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 このリリースで予定されている主な実験的な新機能は、テストの恩恵を受ける可能性が高そうな、 「Simple taproot channel」のサポートです。

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

今週の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 #28492は、PSBTの処理結果が ブロードキャスト可能なトランザクションになる場合、シリアライズされた完全なトランザクションを含めるよう descriptorprocesspsbt RPCを更新しました。同様のマージ済みのPRのについては、 先週のニュースレターをご覧ください。

  • ● Bitcoin Core GUI #119では、GUIのトランザクションのリストが更新され、 「自分自身への支払い（payment to yourself）」という特別なカテゴリを提供しなくなりました。 ウォレットに影響を与えるインプットとアウトプットの両方を持つトランザクションは、 支払いと受け取りで別々の行に表示されるようになりました。 これにより、CoinjoinやPayjoinの分かりやすさが向上しますが、 Bitcoin Coreは現在これらのタイプのトランザクションのどちらもサポートしていません。

  • ● Bitcoin Core GUI #738は、 BerkeleyDB (BDB)に保存されている鍵と暗黙のアウトプットスクリプトタイプに基づくレガシーウォレットを、 SQLiteに保存されるディスクリプターを使用する最新のウォレットに移行できるようにするメニューオプションを追加しています。

  • ● Bitcoin Core #28246は、Bitcoin Coreのウォレットが トランザクションで支払うべきアウトプットスクリプト（scriptPubKey）を内部的に決定する方法を更新しました。 これまでは、トランザクションはユーザーが指定したアウトプットスクリプトに支払うだけでしたが、 サイレントペイメントがBitcoin Coreでサポートされた場合、 アウトプットスクリプトはトランザクション用に選択されたインプットのデータに基づいて導出する必要があります。 今回のアップデートにより、それがさらに簡単になりました。

  • ● Core Lightning #6311は、標準のCLNバイナリに追加オプションを備えたバイナリを生成する --developerビルドオプションを削除しました。実験的な非デフォルト機能にアクセスするには、 --developerランタイム設定オプションを指定してlightningdを起動します。 --enable-debugビルドオプションは、引き続きテストに有益な変更が加えられた若干異なるバイナリを生成します。

  • ● Core Lightning #6617は、showrunes RPCを更新し、 rune （認証トークン）が最後に使用された時間を表示する新しいフィールドlast_usedを提供します。

  • ● Core Lightning #6686は、CLNのAPIのRESTインターフェースに対して設定可能な CSP（Content-Security-Policy）とCORS（Cross-Origin-Resource-Sharing）ヘッダーが追加されました。

  • ● Eclair #2613により、Eclairは自身の秘密鍵をすべて管理し、 監視専用ウォレット（公開鍵はあるが秘密鍵は持たないウォレット）のみでBitcoin Coreを使用できるようになりました。 これは、EclairがBitcoin Coreよりも安全な環境で実行されている場合に特に役立ちます。 詳細については、このPRで追加されたドキュメントをご覧ください。

  • ● LND #7994は、Taprootチャネルを開くためのサポートをリモートサイナーRPCに追加しました。 これには、公開鍵とMuSig2の2部構成のnonceを指定する必要があります。

  • ● LDK #2547は、リモートチャネルの流動性のほとんどがチャネルの片側に押し出されている可能性が高いと仮定して、 確率的経路探索のコードを更新しました。たとえば、アリスとボブの1.00 BTCのリモートチャネルでは、 可能性が最も低いチャネルの状態は、アリスとボブが0.50 BTCずつ持っている状態です。 どちらかが0.90 BTC持っている可能性の方が高く、0.99 BTC持っている方がさらに可能性が高いという状態です。

  • ● LDK #2534は、支払いの送信を試みる前に支払いの経路を調査する（プロービング）ための ChannelManager::send_preflight_probesメソッドを追加しました。 プロービングは通常のLN支払いと同様に送信者によって生成されますが、 そのHTLCのプリイメージの値は使用できない値（たとえば送信者のみが知っている値）が設定されます。 宛先に到着すると、受信側はプリイメージを知らないため、拒否し、エラーを返します。 そのエラーを受け取った場合、その送信者は、送信時に支払いをサポートするのに十分な流動性がその経路にあったことを知り、 同じ金額で同じ経路を通って送信された実際の支払いは成功する可能性が高いでしょう。 経路の途中のホップの1つが支払いを転送できなかったことを示すエラーのような、異なるエラーを受信した場合、 実際の支払いを送信する前に、新しい経路を調査することができます。

    プリペイメント（プリフライト）プロービングは、遅延の原因となる可能性のある問題を抱えているホップを見つけるために、 少額の資金で有用です。数百 sat（またはそれ以下）が数時間滞っても、ほとんどの支払人にとっては大したことではありません。 しかし、ノードの資本のかなりを占める支払いの全額が滞ってしまうと、非常に迷惑なことになります。 また、いくつかの経路を同時に調査し、その結果を使用して、数分後に支払いを送信する際に最適な経路を選択することも可能です。