今週のニュースレターでは、長期的なブロック報酬の調達、BIP47の再利用可能なペイメントコードの代替案、 LNチャネルのスプライスを通知するためのオプション、 LNルーティング手数料の徴収戦略およびオニオンメッセージのレート制限について掲載しています。 また、新しいソフトウェアリリースおよびリリース候補の発表や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点など、恒例のセクションも含まれています。

ニュース

  • 長期的なブロック報酬の調達: 表向きはCovenantsに関するBitcoin-Devメーリングリストのスレッドで、 Bitcoinの長期的なセキュリティは、現在ブロックスペースの需要に依存しているという指摘がありました。 その需要は、攻撃者がBitcoinユーザーを混乱させるために購入しようとする金額を超える、 Proof of Work(PoW)に対して支払うトランザクション手数料を生み出す必要があます。 開発者のPeter Toddは、Bitcoinプロトコルが永続的な報酬を生むように修正されれば、 この依存性を取り除くことができると指摘しました。 何人かの回答者は、永続的な報酬が無い方が良いと考えていることを示し、 他の回答者は、代替案やデマレージなどの明白な同等物を挙げました。

    この記事を書いている時点では、このスレッドは、 近い将来にBitcoinを変更するための特定の提案を支持するというよりも、 カジュアルな会話で構成されているようでした。

  • BIP47の再利用可能なペイメントコードの代替案のアップデート: 開発者のAlfred Hodlerは、運用環境での使用中に発見されたいくつかの問題に対処しようとするBIP47の代替案を Bitcoin-Devメーリングリストに投稿しました。 BIP47では、アリスがペイメントコードを公開し、誰でもそれを自分の鍵と組み合わせて使用することで、 自分とアリスしか知らないアリスのプライベートアドレスを無制限に作成することができ、 アドレスの再利用という最悪の問題を回避することができます。

    しかし、BIP47の問題の1つは、支払い者のボブから受信者のアリスへの最初のトランザクションが、 ペイメントコードに関連付けられた特別なアドレスを使用する通知トランザクションであるということです。 これは、アリスのペイメントコードを知っている第三者に、誰かが支払いを始める予定であることが確実に漏れます。 もし、ボブのウォレットが通知トランザクションに使用される資金を分離するよう慎重に設計されていない場合、 そのトランザクションは、ボブがアリスに対して支払いをしようとしていることを漏らすかもしれません。 これは、BIP47のメリットを減らす、あるいは無くすことになるかもしれません。

    Hodlerの方式は、この情報を漏らす可能性は低くなりますが、 このプロトコルを実装するクライアントがブロックチェーンから学習する必要のあるデータ量が増えるため、 軽量クライアントには不向きです。Ruben Somsenは、 Somsenのサイレントペイメントのアイディア(ニュースレター #194参照)、 Robin Linusの2022年のステルスアドレスのアイディア、 BIP47の改良についてメーリングリストに投稿された過去の議論など、 調査可能ないくつかの代替案を示しました。

  • スプライスの通知: Lightning-DevメーリングリストのPR議論において、 開発者は、オンチェーンで閉じられたように見えるチャネルが、 実際はチャネルに資金が追加または削除されたスプライスであることを伝える最良の方法について議論しました。

    1つの提案は、オンチェーンでクロージング・トランザクションが確認されてからある程度の時間が経つまで、 ノードはチャネルを閉じたとみなさないというものでした。これにより、 新しい(スプライス後の)チャネルの通知が伝播するするための時間が与えられます。 スプライスされたチャネルは、新しいチャネルを開くトランザクションが適切な数の承認を受ける前でも、 完全なLNのセキュリティで支払いを転送できるため、 その間、ノードは閉じられたように見えるチャネルを通じて支払いをルーティングしようとします。

    もう1つの提案は、クロージング・トランザクションの一部として、 スプライスが進行中であることを示すシグナルをオンチェーンに含め、 ノードにそれを通じて支払いの転送の試みを継続できることを伝えるというものでした。

    この要約が書かれた時点では、議論は明確な結論に至っていません。

  • LN転送ノードの基本的な手数料徴収戦略: 開発者ZmnSCPxjは、 LN転送ノードがルーティング支払いの手数料を徴収する際に使える3つの戦略 (手数料を徴収しない戦略を含む)をまとめました。 そして、ZmnSCPxjは、異なる戦略によって起こりうる結果を分析しています。 これは、ニュースレター #204に掲載した、 支払いの成功率を向上させるためにノードがルーティング手数料を使用するという彼の提案に関連しているようで、 この1週間でAnthony Townsからも重要な追加のコメントが寄せられています。

  • オニオンメッセージのレート制限: Bastien Teinturierは、 Rusty Russellが提案したオニオンメッセージの制限に関するアイディアの要約を投稿しました。 この提案では、各ノードが各ピア毎に32バイトの情報を追加で保存し、 過剰なトラフィックを送信するピアに確率的にペナルティを与えることができます。 提案されたペナルティは、過剰なトラフィックを中継するピアのレート制限を約30秒間半減させるというものです。 この軽量なペナルティは、このアイディアで起こりうるように、時折間違ったピアに対して適用されることがあっても許容できます。 この提案では、メッセージの発信者は、どの下流のノードがメッセージをレート制限しているかを(これも確率的に)知ることができ、 別のルートでメッセージを再送信する機会を得ます。

    Olaoluwa Osuntokunは、データ中継に課金することでオニオンメッセージの悪用を防ぐという 彼の以前の提案(ニュースレター #190参照)の再考を提案しました。 この記事を書いている時点では、他の開発者からの回答は、 オニオンメッセージに対する支払いという複雑な方法を追加する前に、 まず軽量なレート制限を試して、それがうまくいくかどうか確認することが望ましいとしています。

リリースとリリース候補

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

  • LDK 0.0.109は、このLNノードライブラリの新しいリリースで、 以下の注目すべき変更のセクションでLDKについて説明されている両方の新機能が含まれています。

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

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

  • Bitcoin Core #24836は、 将来パケージリレーを使用する予定のL2プロトコルおよびアプリケーション開発者が、 Bitcoin Coreのデフォルトのパッケージポリシーに対してトランザクションをテストできるように、 regtest専用のRPCであるsubmitpackageを追加しました。 現在のポリシーはここにまとめられています。 このRPCは、提案中のパッケージRBFルールなど、将来の追加や変更をテストするためにも使用できます。

  • Bitcoin Core #22558は、Taproot用のBIP371の追加のPSBT フィールド(ニュースレター #155参照)のサポートを追加しました。

  • Core Lightning #5281は、複数のログファイルに書き込むためにlog-file設定オプションを複数回設定できるようにしました。

  • LDK #1555は、経路探索のコードをアップデートし、 チャネルにコミットされた金額の半分以上の支払いを受け入れないと宣言しているチャネルを経由するルーティングをわずかに優先するようにしました。 これは、第三者がチャネルを探査する(決済するつもりのない支払い(HTLC)を送信する)ことで発見できる残高情報の量を制限することで、 プライバシーをわずかに向上させると考えられています。 もし、チャネルの合計額までの支払いのセットが送信可能であれば、探索者は異なる支払いのセットを、全てが受け入れられるまで試すことで、 チャネルのほぼ正確な残高を知ることができます。しかし、送信可能な支払いのセットがチャネル残高の半分に制限されている場合、 探索者は、チャネルの一方が資金不足のために支払いが拒否されているのか、 それとも自ら課した制限(max_htlc_in_flight_msatの制限)のために拒否されているのかを判断するのが困難になります。 BOLT2max_htlc_in_flight_msatの制限はゴシップされないため、 LDKは代わりに各チャネルでゴシップされたBOLT7htlc_maximum_msatの値を代替値として使用します。

  • LDK #1550は、ローカルの禁止リストにノードを追加する機能を提供し、 これらのノードを経由した支払いの経路探索を防止します。

  • LND #6592は、サブサーバーに新しいrequiredreserveRPCを追加し、 ウォレットが一方的にコントロールするUTXOでリザーブしているsatoshiの量を出力し、 必要に応じてAnchor Outputによる手数料の引き上げを行うようにしました。 追加の--additionalChannels RPCパラメーターは、整数の引数を取り、 その数の追加のチャネルが開設された場合にウォレットがリザーブするsatoshiの量をレポートします。

  • Rust Bitcoin #1024は、開発者がSIGHASH_SINGLE “バグ”を回避するのに役立つコードを追加しました。 これは、Bitcoinのプロトコルで、SIGHASH_SINGLEの署名を含むインプットが、 トランザクション内のアウトプットのインデックス番号よりも大きい場合に、値1に署名されることを想定するものです。

  • BTCPay Server #3709は、LNURLの引き出しによって受け取られるプルペイメントをサポートしました。

  • BDK #611は、新しいトランザクションのnLockTimeをデフォルトで最新ブロックの高さに設定し、 アンチ・フィー・スナイピングを有効にしました。