今週のニュースレターでは、カジュアルなLNユーザーが一度に最大数ヶ月オフラインでいられるようにする提案と、 トランザクション情報サーバーが未使用のウォレットアドレスをホストできるようにすることに関するドキュメントを掲載しています。 また、Bitcoin Core PR Review Clubの概要や、新しいソフトウェアリリースおよびリリース候補の発表(重要なLNDの修正を含む)、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • タイムアウトの長いLNの提案: John Lawは、 カジュアルなライトニングユーザーが、チャネルパートナーとの間で資金を失うリスクなく最大数カ月間オフラインでいられるようにする提案を Lightning-Devメーリングリストに投稿しました。 これは、現在のLNプロトコルでも技術的に可能ですが、清算の遅延パラメーターに高い値を設定する必要があり、 嫌がらせをするユーザーや事故によって多数のチャネルが同じ期間使用できなくなります。 Lawの提案は、2つのプロトコルの変更でこの問題を軽減します。:

    • トリガーHTLC: 支払いに使用する標準のHTLCでは、 既知のハッシュダイジェストに対して、ボブが未知のプリイメージを公開できたら、 アリスはボブにいくらかのBTCを提供します。もしくは、ボブがある時間までにプリイメージを公開しなければ、 アリスはその資金を自分のウォレットに戻すことができます。

      Lawは、ボブは引き続きプリイメージを公開すればいつでも支払いを受けることができますが、 アリスには追加の制限を課すことを提案しています。アリスは、オンチェーンで承認されるトリガートランザクションによって、 自分のウォレットの資金を戻す意思をボブに明確に警告する必要があります。 トリガートランザクションが一定のブロック数(もしくは時間)承認された場合のみ、アリスは資金を使用することができます。

      これにより、通常のHTLCがタイムアウトしてから数ヶ月経ったとしても、 トリガートランザクションが合意した数の承認を得るまで、ボブがいつでも支払いを受けることができることを保証します。 ボブは待ち時間に対して十分な補償があれば、アリスがその間オフラインのままであっても問題はないでしょう。 アリスからボブを経由してルーティングされるHTLCについては、アリスとボブのチャネルのみが影響を受け、 他のすべてのチャネルは(現在のLNプロトコルのように)速やかにHTLCを清算することになります。

    • 非対称の遅延コミットメントトランザクション: LNチャネルの2人の参加者は、それぞれ未公開のコミットメントトランザクションを保持しており、 いつでもそれを公開して承認させようとすることができます。 この両者のトランザクションは同じUTXOを使用するため、競合します。つまり、実際に承認されるのはどちらか1つだけです。

      これは、アリスがチャネルを閉じたい場合に、単純に自分のコミットメントトランザクションを適切な手数料率でブロードキャストして、 それが承認されると仮定することができないことを意味します。 アリスは、ボブが代わりに彼のコミットメントトランザクションを承認させるかもしれないため、待機して確認する必要があります。 この場合、ボブのトランザクションが最新のチャネル状態かどうか追加の確認をする必要があります。

      Lawは、アリスのコミットメントトランザクションは現在と同じままいつでも公開でき、 ボブのトランザクションについてはタイムロックを含め、アリスが長期間アクティブでない場合にのみ公開できるようにすることを提案しています。 理想的には、これによりアリスはボブが両立しないバージョンのトランザクションを公開できないことを認識して最新の状態を安全に公開することができ、 公開後に安全にオフラインになることができます。

    Lawの提案は、この記事の執筆時点で、まだ初期のフィードバックを受けています。

  • 固有のアドレスサーバーについての推奨事項: Ruben Somsenは、 ユーザーがサードパーティのサービスを信頼したり、 BIP47Silent Paymentなど現在広くサポートされていない暗号プロトコルを使用したりすることなく、 アウトプットのリンク付けを回避する方法について、別の提案を含むドキュメントを Bitcoin-Devメーリングリストに投稿しました。 推奨される方法は、パブリックなアドレスルックアップサーバーを使用しているウォレット(軽量ウォレットの大部分と考えられる)など、 既にサードパーティにアドレスを提供しているウォレットを対象としています。

    この方法がどう機能するかの例として、アリスのウォレットがExample.comのelectrumスタイルのサーバーに100個のアドレスを登録したとします。 次に、メールの署名に「example.com/alice」を含めます。 ボブがアリスに寄付をしたい場合、彼はこのURLにアクセスしアドレスを入手し、 アリスがそれに署名したことを確認してからそのアドレスに支払いをします。

    このアイディアは、一部の手動プロセスを介して多くのウォレットと互換性があり、 おそらく自動化されたプロセスで簡単に実装できるという利点があります。 欠点は、サーバーとアドレスを共有することで既にプライバシーを損なっているユーザーが、 さらにプライバシーの喪失にコミットすることになることです。

    この要約が書かれている時点では、メーリングリストとドキュメントの両方で提案に関する議論が進行中でした。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Make AddrFetch connections to fixed seedsは、Martin ZumsandeによるPRで、 AddrMan(ピアのデータベース)に追加するだけでなく、 固定シード(ハードコードされたIPアドレス)へのAddrFetch接続を作成します。

  • 新しいノードがゼロから起動する際、最初にいくつかのピアと接続し、そこからIBD(Initial Block Download)を実行する必要があります。 どのような場合に固定シードに接続するのでしょうか?

    ハードコードされたBitcoinのDNSシードノードから提供されるアドレスのピアに接続できない場合のみです。 これは、ノードがIPv4やIPv6を使用しないよう設定されている場合(例えば、-onlynet=tor)に最もよく発生します。 

  • このPRはどのような動作の変更をもたらしますか?どんな種類のアドレスをどんな状況下でAddrManに追加するのですか?

    ノードは、すぐに固定シードをAddrManに追加しそれらのいくつかに完全な接続をするのではなく、 代わりにそれらのいくつかにAddrFetch接続を行い、返されたアドレスをAddrManに追加します。 (AddrFetchはアドレスのフェッチのみに使用される短期接続です。) その後、ノードはAddrMan内のいくつかのアドレスに接続し、IBDを実行します。 これにより、固定シードのノードへの完全な接続は少なくなり、 固定シードが教えるノードより大きなノードセットから、より多くの接続が試行されます。 AddrFetch接続は、例えばtorなど、あらゆるタイプの接続を返すことができ、IPv4やIPv6に限定されません。 

  • なぜ、固定シードへの完全なアウトバウンド接続よりAddrFetch接続を行いたいのでしょうか? 固定シードのノードオペレーターがこれを好むのはなぜですか?

    AddrFetch接続は、私達のノードがより大きなピアのセットからIBDピアを選択することを可能にし、 ネットワーク接続を全体的により分散させます。 固定シードのノードオペレーターは、同時に複数のIBDピアを持つ可能性が低くなり、 彼らのノードのリソース要件が減少します。 

  • DNSシードは応答性が高く、Bitcoinノードの最新のアドレスを提供することが期待されます。 なぜこれが-onlynet=torのノードに役立たないのでしょうか?

    TDNSシードノードは、IPv4およびIPv6アドレスのみを提供し、他の種類のアドレスは提供できません。 

リリースとリリース候補

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

  • LND v0.15.2-betaは、セキュリティ上重要な緊急リリースで、 LNDが特定のブロックをパースできないパースエラーを修正しています。すべてのユーザーにアップグレードが必要です。

  • Bitcoin Core 24.0 RC1は、ネットワークで最も広く使われているフルノード実装の次期バージョンの最初のリリース候補です。 テストのガイドが利用できるようになっています。

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

今週のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)、およびLightning BOLTsの注目すべき変更点。

  • LND #6500では、Torの秘密鍵を平文で保存するのではなく、ウォレットの秘密鍵を使ってディスク上で暗号化する機能が追加されました。 --tor.encryptkeyフラグを使用すると、LNDは秘密鍵を暗号化し、暗号化Blobがディスク上の同じファイルに書き込まれます。 これによりユーザーは同じ機能を維持しつつ(Hidden Serviceの参照など)、信頼されない環境で実行する際の保護を追加できます。