en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #256

Jun 21, 2023

今週のニュースレターでは、BOLT11インボイスを拡張して2つの支払いを要求することについての議論を掲載しています。また、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、クライアントとサービスのアップデート、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャプロジェクトの変更など、恒例のセクションも含まれています。

ニュース

● BOLT11インボイスを拡張して2つの支払いを要求する提案: Thomas Voegtlinは、 BOLT11インボイスを拡張して、オプションで受信者が支払人に2つの別々の支払いを要求できるようにし、それぞれの支払いには別々のシークレットと金額を持たせる提案を、Lightning-Devメーリングリストに投稿しました。 Voegtlinは、これがサブマリン・スワップとJITチャネルの両方にどう役立つかを説明しています。
- ● サブマリン・スワップは、オフチェーンでLNインボイスに支払うことで、オンチェーンで資金を受け取ることができます（サブマリン・スワップは、オンチェーンからオフチェーンへ逆方向にも機能しますが、ここでは議論しません）。オンチェーンの受信者はシークレットを選択し、オフチェーンの支払人はそのシークレットのハッシュに対してHTLCを支払い、これがLN経由でサブマリン・スワップのサービスプロバイダーにルーティングされます。サービスプロバイダーは、そのシークレットに対するオフチェーンHTLCを受け取り、そのHTLCに支払うオンチェーントランザクションを作成します。ユーザーがオンチェーントランザクションが安全であると納得したら、オンチェーンHTLCを決済するためにシークレットを開示し、サービスプロバイダーがオフチェーンHTLC（および同じシークレットに依存するLN上のすべての転送された支払い）を決済できるようにします。
  
  しかし、受信者がシークレットを開示しなかった場合、サービスプロバイダーは報酬を受け取ることができず、作成したばかりのオンチェーンアウトプットを使用する必要があり、無駄なコストが発生します。このような悪用を防ぐため、既存のサブマリン・スワップサービスは、サービスがオンチェーントランザクションを作成する前に、支払人にLNで手数料の支払いを求めます（サービスはオプションで、オンチェーンHTLCが決済された場合に、この手数料の全額または一部を返金することができます）。前払い手数料の金額とサブマリン・スワップの金額は異なる金額で、異なるタイミングで決済する必要があるため、異なるシークレットを使用する必要があります。現在のBOLT11インボイスは、 1つのシークレットと1つの金額に対するコミットメントしか含めることができないため、現在サブマリン・スワップを行うウォレットは、サーバーとやりとりするようにプログラムされているか、支払人と受信者の双方が複数のステップのワークフローを完了する必要があります。
- ● JIT（Just-in-Time）チャネルは、チャネル（または流動性）を持たないユーザーが、サービスプロバイダーと仮想チャネルを作成します。その仮想チャネルに最初の支払いが到着すると、サービスプロバイダーがチャネルに資金を供給しその支払いを含むオンチェーントランザクションを作成します。他のLNのHTLCと同様に、オフチェーン支払いは受信者（ユーザー）だけが知っているシークレットに対して行われます。ユーザーがJITチャネルのファンディング・トランザクションが安全であると納得したら、支払いを請求するためのシークレットを開示します。
  
  しかし、この場合も、ユーザーがシークレットを開示しなければ、サービスプロバイダーは対価を受け取れず、オンチェーンコストが発生し、何の利益も得られません。 Voegtlinは、既存のJITチャネルのサービスプロバイダーは、ファンディング・トランザクションが安全になる前にユーザーにシークレットの開示を要求することで、この問題を回避していると考えており、これは法的な問題を引き起こす可能性があり、非カストディアルウォレットが同様のサービスを提供することを妨げると述べています。
Voegtlinは、BOLT11インボイスにそれぞれ異なる2つのシークレットと金額に対するコミットメントを含めることを許可することで、一方のシークレットと金額をオンチェーントランザクションのコストを支払う前払い手数料として使用し、もう一方のシークレットと金額を実際のサブマリン・スワップまたはJITチャネルの資金に使用できるようになると提案しています。この提案には、いくつかのコメントが寄せられており、そのうちのいくつかを要約します:
- ● サブマリン・スワップに必要な専用ロジック: Olaoluwa Osuntokunは、サブマリン・スワップの受信者はシークレットを作成、配布し、それに対する支払いをオンチェーンで決済する必要があると指摘しています。それを決済する最も安価な方法は、スワップのサービスプロバイダーと対話することです。支払人と受信者が同じエンティティである既存の実装によくあるように、支払人と受信者がサービスプロバイダーと対話する場合は、インボイスを使って追加の情報を伝達する必要はありません。 Voegtlinは、専用のソフトウェアがこのやりとりを処理することで、資金を支払うオフチェーンウォレットと資金を受け取るオンチェーンウォレットに追加のロジックが不要になり、ただし、これが可能になるのは、LNウォレットが同じインボイスで2つの別々のシークレットと金額を支払うことができる場合に限られると回答しました。
- ● BOLT11の硬直化: Matt Coralloは、（Spontaneous Paymentを許可するための）金額を含まないインボイスをサポートするために、すべてのLN実装がBOLT11サポートを更新することはまだ不可能であり、追加フィールドを追加することは現時点では現実的なアプローチとは思えないと回答しました。 Bastien Teinturierも同様のコメントをしており、代わりにオファーにサポートを追加することを提案しています。 Voegtlinはこれに反対し、サポートを追加するのが現実的だと考えています。
- ● スプライス・アウトという選択肢: Coralloは、スプライス・アウトが利用できるようになった場合、なぜプロトコルを変更してサブマリン・スワップをサポートする必要があるのかについても尋ねています。スレッドでは言及されていませんでしたが、サブマリン・スワップとスプライス・アウトはどちらもオフチェーンの資金をオンチェーンのアウトプットに移動させることができます。ただし、スプライス・アウトはオンチェーンではより効率的であり、補償されない手数料の問題に対して脆弱ではありません。 Voegtlinは、サブマリン・スワップにより、LNユーザーは新しいLN支払いを受け取るためのキャパシティを増やすことができるが、スプライシングではそれができないと答えています。
この記事の執筆時点でも議論は続いているようです。

承認を待つ #6: ポリシーの一貫性

トランザクションリレーや、mempoolへの受け入れ、マイニングトランザクションの選択に関する限定週刊シリーズです。 Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持っている理由や、ウォレットがそのポリシーを最も効果的に使用する方法などが含まれます。

先週の記事では、コンセンサスルールに加えて適用されるトランザクションの検証ルールのセットであるポリシーについて紹介しました。これらのルールは、ブロック内のトランザクションには適用されないため、ノードのポリシーがピアと異なっていても、コンセンサスを維持することができます。ノードオペレーターがトランザクションリレーに参加しないことを選択できるように、どのようなポリシーを選択するかも自由で、全く選択しない（ノードがDoSのリスクにさらされる）ことも可能です。つまり、ネットワーク全体でmempoolポリシーが完全に同一であるとは仮定できません。しかし、ユーザーのトランザクションがマイナーに受信されるためには、すべてのノードがそのトランザクションを自身のmempoolに受け入れる経路を通過する必要があり、ノード間のポリシーの不一致はトランザクションリレーの機能に直接影響します。

ノード間のポリシーの違いの極端な例として、各ノードオペレーターがランダムなnVersionを選択し、そのnVersionのトランザクションのみを受け入れるという状況を想像してみてください。ほとんどのピアツーピアの関係は互換性のないポリシーを持つことになるので、トランザクションはマイナーまで伝播しません。

一方、ネットワーク全体で同一のポリシーがあれば、mempoolの内容を収束させることができます。 mempoolが一致するネットワークは、トランザクションを最もスムーズにリレーし、これまでの記事で説明したように、手数料の推定やコンパクトブロックリレーにも最適です。

mempoolの検証の複雑さとポリシーの不一致から生じる困難を考慮し、 Bitcoin Coreは歴史的にポリシーの設定可能性に関して保守的でした。ユーザーは、sigopsのカウント方法（bytespersigop）を簡単に微調整したり、 OP_RETURNアウトプットに埋め込めるデータ量を制限したり（datacarriersizeおよびdatacarrier）できる一方で、ソースコードを変更することなく、400,000 weight-unitの最大標準weightをオプトアウトしたり、手数料関連のRBFルールに異なるセットを適用したりすることはできません。

Bitcoin Coreのポリシー設定オプションの中には、ノードの動作環境の違いや、運用目的の違いに対応するためのものが存在します。たとえば、マイナーのハードウェアリソースやmempoolを維持する目的は、ラップトップやRaspberry Piで軽量ノードを実行する日常的なユーザーとは異なります。マイナーはmempoolの容量（maxmempool）や有効期限のタイムライン（mempoolexpiry）を増やしてトラフィックピーク時の低手数料率のトランザクションを保存し、トラフィックが落ち着いたときにそれらをマイニングするかもしれません。可視化やアーカイブ、ネットワーク統計を提供するウェブサイトでは、できるだけ多くのデータを収集するために複数のノードを実行し、デフォルトのmempoolの動作を表示することもあります。

個々のノードでは、mempoolの容量の選択が手数料引き上げツールの可用性に影響します。デフォルトのmempoolサイズを超えるトランザクションの送信により、 mempoolの最小手数料率が上昇すると、mempoolの「底」からパージされたトランザクションと、この手数料率を下回る新しいトランザクションは、CPFPを使って手数料を引き上げられなくなります。

一方、パージされたトランザクションによって使用されていたインプットは、 mempool内のどのトランザクションも使用していないので、以前はできなかった RBFによる手数料の引き上げが可能になるかもしれません。新しいトランザクションは、ノードのmempool内の何かを実際に置き換えているわけではないので、通常のRBFルールを考慮する必要はありません。しかし、（より大きなmempool容量を持つため）元のトランザクションをパージしていないノードは、新しいトランザクションを提案された置換トランザクションとして扱い、 RBFルールへの準拠を要求します。パージされたトランザクションがBIP125の置換可能性をシグナルしていなかったり、新しいトランザクションの手数料が高い手数料率にも関わらずRBFの要件を満たしていない場合、マイナーはその新しいトランザクションを受け入れない可能性があります。ウォレットはパージされたトランザクションを注意深く扱う必要があります。トランザクションのアウトプットは使用可能とは見なせませんが、インプットは同様に再利用することはできません。

一見すると、より大きなmempool容量を持つノードは、CPFPの有用性が高くRBFの有用性が低いように見えるかもしれません。しかし、トランザクションのリレーは、ネットワークの創発的な挙動に左右され、ユーザーからマイナーまでCPFPを受け入れるノードの経路が存在しないかもしれません。ノードは通常、トランザクションをmempoolに受け入れた時に一度だけそれをリレーし、自分のmempoolに既に存在するトランザクションの通知を無視します。より多くのトランザクションを格納するノードは、それらのトランザクションが再度ブロードキャストされたときにブラックホールとして機能します。ネットワーク全体がmempoolの容量を増やさない限り（デフォルト値を変更する変調）、自分自身のmempoolの容量を増やすことで利益を得ることはほとんど期待できないでしょう。デフォルトのmempoolの最小手数料率は、トラフィックピーク時にCPFPを使用することの有用性を制限しています。サイズを拡大した自分のmempoolにCPFPトランザクションを送信できたユーザーは、そのトランザクションが他の誰にも伝播していないことに気づかないかもしれません。

トランザクションリレーネットワークは、ネットワークに動的に参加および離脱する個々のノードで構成されており、それぞれが悪用から身を守る必要があります。そのため、トランザクションリレーはベストエフォート型でしかなく、すべてのノードがすべての未承認トランザクションを学習することを保証することはできません。同時に、Bitcoinネットワークは、mempoolを可能な限り均質にするトランザクションリレーポリシーの1セットに収束すれば、最高のパフォーマンスを発揮します。次の記事では、ネットワーク全体の利益に適合するために、どのようなポリシーが採用されているかを探ります。

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

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

● Greenlightライブラリがオープンソースに: 非カストディアルのLNノードサービスプロバイダーGreenlightは、クライアントライブラリと言語バインディングのリポジトリと、テストフレームワークガイドを発表しました。
● TapscriptデバッガーTapsim: Tapsimは、スクリプト実行のデバッグ（ニュースレター #254参照）および btcdを使用したTapscriptの可視化ツールです。
● Bitcoin Keeper 1.0.4の発表: Bitcoin Keeperは、マルチシグ、ハードウェア・サイナー、BIP85をサポートするモバイルウォレットで、最新のリリースでは、Whirlpoolプロトコルを使用したCoinjoinをサポートしています。
● ライトニングウォレットEttaWalletの発表: LDKによって可能になったライトニングの機能を備え、 Bitcoin Design Communityの日常的な支払いウォレットの参照設計からインスピレーションを得たユーザービリティ重視のモバイルEttaWalletが最近発表されました。
● zkSNARKベースのブロックヘッダー同期のPoCの発表: BTC Warpは、zkSNARKsを使用してBitcoinのブロックヘッダーのチェーンの証明および検証を行う軽量クライアントの同期の概念実証です。ブログ記事には、採用されたアプローチの詳細が記載されています。
● lnprototest v0.0.4リリース: lnprototestプロジェクトは、「Python3で書かれたテストヘルパーのセットで、ライトニングネットワークプロトコルの変更を提案する際に、新しいテストを簡単に書くことができ、また既存の実装をテストできるように設計されている」 LNのテストスイートです。

リリースとリリース候補

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

● Eclair v0.9.0は、このLN実装の新しいリリースで、「重要な（そして複雑な）ライトニングの機能：デュアル・ファンディング、スプライシング、BOLT12 オファーのための多くの準備作業を含んでいます。」これらの機能は現時点では実験的なものです。このリリースでは、「プラグインがより強力になり、さまざまな種類のDoSに対する緩和策が導入され、コードベースの多くの領域でパフォーマンスが向上します」とあります。

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

今週の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の注目すべき変更点。

● LDK #2294は、Onionメッセージへの返信をサポートし、 LDKのオファーの完全なサポートに近づけました。
● LDK #2156は、簡略化されたマルチパスペイメントを使用した keysend支払いをサポートしました。 LDKは以前、この2つの技術の両方をサポートしていましたが、それはそれらが別々に使用されていた場合にのみでした。マルチパスペイメントはペイメント・シークレットを使用する必要がありますが、 LDKは以前、ペイメント・シークレットを使用したkeysend支払いを拒否していたため、潜在的な問題を軽減するために、説明的なエラーや設定オプションおよびダウングレードに関する警告が追加されました。