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

ニュース

  • ● マルチパーティチャネルやチャネルファクトリーでの資金滞留を防止する: John Lawは、彼の書いた論文の概要をLightning-Devメーリングリストに投稿しました。 彼は、現在利用できないノード（モバイルLNウォレットのユーザーなど）とチャネルを共有している場合でも、 常時利用可能なノードが自身の資金を使用して支払いを転送し続けられるようにする方法について説明しています。 これには、マルチパーティチャネルを使用する必要があり、彼が以前説明したチャネルファクトリーの設計とうまく構成できます。 彼はまた、チャネルをオフチェーンでリバランスできるというチャネルファクトリーの 既知の利点を再度述べています。これにより資金の有効活用が可能になる可能性があります。 この2つの利点を、彼が以前考案したLNの Tunable Penalty レイヤーの文脈で利用する方法を説明しています。 ここでは、Tunable Penaltyを要約し、それがどのようにマルチパーティチャネルや、 チャネルファクトリーで使用できるかを説明し、その後Lawの新しい結果を文脈に沿って説明します。

    アリスとボブは、それぞれ50M sat（合計100M sat）を、使用時に両者の協力が必要な ファンディング・アウトプット に支払うトランザクションを作成します（ただしすぐには署名しません）。 以下の図では、承認されたトランザクションを網掛けしています。

    アリスとボブがファンディング・トランザクションを作成

    また、それぞれ個別に制御する異なるアウトプットを使用して、両者に１つずつ、2つの ステート・トランザクション を作成します（ただし、ブロードキャストはしません）。各ステート・トランザクションの最初のアウトプットは、 タイムロックされたオフチェーンの コミットメント・トランザクション へのインプットとして小額（たとえば1,000 sat）を支払います。 相対的なタイムロックにより、各コミットメント・トランザクションは、 その親のステート・トランザクションがオンチェーンで承認された後、一定時間経過するまで、 オンチェーンでの承認の対象になりません。 また、それぞれの2つのコミットメント・トランザクションは、 競合するファンディング・アウトプットから資金提供されています（つまり、 どちらかのコミットメント・トランザクションのみが最終的に承認されます）。 すべての子トランザクションが作成されたら、ファンディング・アウトプットを作成するトランザクションに 署名してブロードキャストできます。

    アリスとボブがそれぞれコミットメント・トランザクションを作成

    各コミットメント・トランザクションは、チャネルの現在の状態に対して支払いをします。 初期状態(S0)では、50M satがアリスとボブにそれぞれ払い戻されます（単純にするため、トランザクション手数料は無視します）。 アリスとボブは、自身のバージョンのステート・トランザクションを公開することで、 チャネルを一方的に閉じるプロセスを開始できます。強制的な遅延の後、 続いて対応するコミットメント・トランザクションを公開できるようになります。 たとえば、アリスが自分のステート・トランザクションと （自分とボブに支払いをする）コミットメント・トランザクションを公開します。 その時点で、ボブは自分のステート・トランザクションを使用することはできず、 代わりに、ステート・トランザクションを作成するために使用した資金を後で好きに使用できます。

    アリスは正直にチャネルから支払う

    初期状態で一方的にチャネルを閉じる以外に、2つの選択肢があります。 1つは、アリスとボブがファンディング・トランザクションのアウトプットを使用することで、 いつでも協力してチャネルを閉じることができます（現在のLNプロトコルで行われているのと同じです）。 2つめに、両者は状態を更新することができます。たとえば、アリスの残高を10M sat増やし、 ボブの残高を同じ額減らすことができます。状態 S1 は、初期状態( S0 )と似てますが、 前の状態( S0 )の各ステート・トランザクションの最初のアウトプットを使用するために必要な witness1を相手に与えることで、前の状態を取り消すことができます。 S0 ステート・トランザクション自体にはまだwitnessが含まれておらず、ブロードキャストできないため、 どちらの当事者も相手のwitnessを使用することはできません。

    複数の状態が利用できるようになると、誤って、あるいは意図的に、古い状態でチャネルを閉じることが可能です。 たとえば、ボブは10M satoshiを余分に持っている状態 S0 でチャネルを閉じようとするかもしれません。 そうする場合、ボブは彼の S0 のステート・トランザクションに署名し、ブロードキャストします。 コミットメント・トランザクションにはタイムロックがあるため、ボブはそれ以上のアクションをすぐにとることはできません。 その待ち時間の間に、アリスは古い状態がブロードキャストされたことを検出し、 ボブが以前与えたwitnessを使用して、ボブのステート・トランザクションの最初のアウトプットを使用し、 ペナルティ額の一部または全額をトランザクション手数料として使用します。 このアウトプットは、ボブに余分に10M sat支払うコミットメント・トランザクションを ブロードキャストするために必要なアウトプットと同じなので、アリスが作成したトランザクションが承認されると、 ボブはその資金の請求をブロックされることになります。 ボブがブロックされているため、アリスだけが一方的に最新の状態をオンチェーンで公開することができます。 代わりに、アリスとボブはまだいつでも協力してチャネルを閉じることができます。

    ボブがチャネルから不正に支払おうとしてアリスによりブロックされる

    もしボブがアリスが彼の古いステート・トランザクションを使おうとしているのに気づいたら、 アリスとRBF（Replace By Fee）による入札競争を試みることが可能ですが、 この場合、ペナルティ額が 調整可能 であることが特に強力になります。 ペナルティ額は、少額（たとえば、この例のように1K satの場合）か、 ステーク額（10M sat）に近いか、チャネル全体の金額よりも大きい場合があります。 この決定は、チャネルを更新する際に、アリスとボブが互いに交渉することに完全に委ねられています。

    TPP（Tunable-Penalty Protocol）の他の利点の１つは、 古い状態のトランザクションをオンチェーンに投入したユーザーがペナルティ額を全額支払うということです。 共有したファンディング・トランザクションのビットコインは一切使用しません。 これにより、2人以上のユーザーがTPPチャネルを安全に共有できます。 たとえば、アリスとボブ、キャロル、ダンがチャネルを共有しているとしましょう。 各自、自身のステート・トランザクションから資金を得る自身のコミットメントトランザクションを持っています:

    アリスとボブとキャロル、ダンの間のチャネル

    彼らはこれをマルチパーティチャネルとして運用し、各状態が各参加者によって取り消される必要があります。 あるいは、共同のファンディング・トランザクションをチャネルファクトリーとして利用し、 ペアまたは複数のユーザー間で複数のチャネルを作ることも可能です。 昨年、LawがTPPのこの意味について説明する（ニュースレター #230参照）前は、 Bitcoinでチャネルファクトリーを実用化するためにはSIGHASH_ANYPREVOUTのような コンセンサスの変更を必要とするeltooのような仕組みが必要と考えられていました。 TPPはコンセンサスの変更を必要としません。下の図を簡単にするため、 参加者4人のファクトリーで作成された1つのチャネルだけを図示しています。 チャネル参加者が管理する必要のある状態の数は、ファクトリーの参加者の数と等しくなります。 Lawは単一の状態を使用する構成を以前説明していましたが、 一方的にチャネルを閉じる際のコストが高くなります。

    アリスとボブとキャロル、ダンのファクトリーで作られたアリスとボブのチャネル

    元の論文に記載されているチャネルファクトリーの利点は、 ファクトリー内の参加者が、オンチェーントランザクションを作成することなくチャネルを協力的にリバランスできることです。 たとえば、ファクトリーがアリス、ボブ、キャロル、ダンで構成されている場合、 オフチェーンでファクトリーの状態を更新することで、アリスとボブのチャネルの総額を減らし、 キャロルとダンのチャネルの総額を同額分増やすことができます。 LawのTPPベースのファクトリーも同じ利点を提供します。

    今週、Lawはマルチパーティチャネルを提供する機能を持つファクトリー（TPPにより可能になる）には、 1人のチャネル参加者がオフラインの場合でも、資金を使用できるという追加の利点があると指摘しました。 たとえば、アリスとボブは専用のLNノードを持っていて、ほぼ常に支払いを転送することができるものの、 キャロルとダンはカジュアルなユーザーで、そのノードはよく利用できなくなる場合を考えてみましょう。 オリジナルのチャネルファクトリーでは、アリスはキャロルとのチャネル（{A,C}）と ダンとのチャネル（{A,D}）を持っています。キャロルとダンが利用できない場合、 アリスはこれらのチャネルの資金を使用することはできません。 ボブも、（{B,C}と{B,D}のチャネルについて）同じ問題を抱えています。

    TPPベースのファクトリーでは、アリス、ボブ、キャロルでマルチパーティチャネルを開くことができ、 状態の更新にその3人の協力が必要になります。そのチャネルにおいて、 コミットメント・トランザクションのアウトプットの1つはキャロルに支払われますが、 他のアウトプットはアリスとボブが協力した場合にのみ使用することができます。 キャロルが利用できない場合、アリスとボブは協力して共同アウトプットの残高の配分をオフチェーンで変更でき、 他のLNチャネルを持っている場合はLN支払いの実行や転送が可能になります。 アリスが長い間利用できない状態が続くと、どちらかが一方的にチャネルをオンチェーンにすることができます。 アリスとボブがダンとチャネルを共有している場合も、同じ利点が適用されます。

    これにより、キャロルやダンが利用できない時でも、アリスとボブは転送手数料を稼ぎ続けることができ、 それらのチャネルが非生産的であると思われるのを防ぐことができます。 また、オフチェーン（オンチェーン手数料なし）でチャネルのリバランスができるため、 アリスとボブがチャネルファクトリーに資金を長期間置いておくことのデメリットも減らせるかもしれません。 これらの利点を合わせると、オンチェーントランザクションの数を減らし、 Bitcoinネットワークの総支払い能力を高め、LN上で支払いを転送するコストを下げることができます。

    この記事を書いている時点では、Tunable Penaltyとそれを利用するためのLawのさまざまな提案は、 あまり公に議論されていません。

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

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

リリースとリリース候補

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

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

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

  • ● Bitcoin Core #27278は、ノードがIBD（Initial Block Download）中でない限り、 新しいブロックのヘッダーを受信すると、デフォルトでログに記録するようになりました。 これは、複数のノードオペレーターが、3つのブロックがとても近いタイミングで到着し、 後の2つがベストブロックチェーンでの最初のブロックの再編成によるものであることに気づいた事が発端です。 分かりやすくするために、最初のブロックを A、それに置き換わるブロックを A’ 、 最後のブロックを B とします。

    これはブロックA’とBが同じマイナーによって作られたことを示している可能性があり、 他のマイナーのブロックが古くなるまで意図的にブロードキャストを遅らせ、 そのマイナーが通常Aから受け取るはずだったブロック報酬を拒否させる セルフィッシュマイニング として知られる攻撃である可能性があります。 偶然の一致か、セルフィッシュマイニングの可能性もあります。 しかし、調査中に開発者によって提起された１つの可能性は、 タイミングが実際には見かけほど近くはなかった可能性があるというものでした。 A’だけでは再編成を引き起こすには十分ではなかったため、 Bitcoin CoreはBを受信するまでA’を要求しなかった可能性があります。

    ヘッダーを受信した時間をログに記録するのは、将来このような状況が繰り返された場合に、 ノードオペレーターが、自分のノードがすぐにダウンロードを選択しなかったとしても、 いつ最初にA’の存在を知ったかを判断できるようにすることを意味します。 このログの記録により、1ブロックあたり最大2行の新しい行が追加される可能性がありますが（ただし、 将来のPRでは1行に減らされる可能性があります）、これはセルフィッシュマイニング攻撃や、 重要なブロックリレーに関するその他の問題の検出に役立つ、十分に小さなオーバーヘッドであると考えられています。

  • ● Bitcoin Core #26531では、以前のPR（ニュースレター #133参照）で実装された eBPF（Extended Berkeley Packet Filter）を使用してmempoolに影響するイベントを監視するためのトレースポイントを追加しました。 また、トレースポイントを使用してmempoolの統計とアクティビティをリアルタイムで監視するためのスクリプトも追加されました。

  • ● Core Lightning #5898は、libwallyの依存関係をより新しいバージョン（ ニュースレター #238参照）に更新しました。これにより、 TaprootおよびPSBTバージョン2（ニュースレター #128参照）のサポートが追加され、 ElementsスタイルのサイドチェーンのLNサポートに影響します。

  • ● Core Lightning #5986は、msatsで値を返すRPCを更新し、 結果の一部として「msat」という文字列を含めないようにしました。 代わりに、返される値はすべて整数になります。これにより、 いくか前のリリースから始まった非推奨化が完了します（ニュースレター #206参照）。

  • ● Eclair #2616は、日和見的なゼロ承認チャネルのサポートを追加しました。 リモートピアが期待される承認数より前にchannel_readyメッセージを送信した場合、 Eclairはファンディングトランザクションがローカルノードによって完全に作成されたことを確認した上で （つまりリモートピアは競合するトランザクションを作れません）、チャネルの使用を許可します。

  • ● LDK #2024は、ゼロ承認チャネルなど、 開設されたものの承認数が足りずまだ公表されていないチャネルのルートヒントを含めるようになりました。

  • ● Rust Bitcoin #1737は、プロジェクトのセキュリティ報告ポリシーを追加しました。

  • ● BTCPay Server #4608は、プラグインがその機能を BTCPayのユーザーインターフェースのアプリとして公開できるようにしました。

  • ● BIPs #1425は、ニュースレター #239に掲載したように、 BIP32のリカバリーシードをシャミアの秘密分散法（SSSS）アルゴリズムや、 チェックサム、32文字のアルファベットを用いてエンコードするCodex32方式にBIP93を割り当てました。

  • ● Bitcoin Inquisition #22は、0から126バイトのデータをTaprootインプットのannexフィールドにプッシュできる -annexcarrier実行オプションを追加しました。このPRの著者は、Core Lightningのフォークを使用して、 signetでeltooの実験を開始できるようにすることを計画しています。

脚注

  1. このハイレベルの概要では、witnessが何であるか説明することは重要ではありませんが、 提案された利点のいくつかはその詳細に依存します。元のTunable Penaltyプロトコルの説明では、 コミットメント・トランザクションを使用するための署名を生成するために秘密鍵をリリースすることを提案しています。 秘密鍵を順に生成することは可能で、ある秘密鍵を知っている人はその後の鍵も導出することができます （ただし、前の鍵は導出できません）。 これは、アリスが後の状態を破棄するたびに、アリスはボブに以前の鍵を渡すことができ、 ボブはそれを使って（以前の状態に対して）後の鍵を導出することができることを意味します。たとえば、

    チャネルの状態 鍵の状態
    0 MAX
    1 MAX - 1
    2 MAX - 2
    x MAX - x
    MAX 0

    これによりボブは、古い状態のトランザクションを使用するために必要な情報を、 非常に小さな一定量のスペース（計算では100バイト未満）で保存できます。 また、その情報はWatchtowerと簡単に共有できます。 （トラストする必要なく、古いステート・トランザクションの使用が成功すると、 古いコミットメントトランザクションがオンチェーンで公開されるのを防ぐことができます。 古いステート・トランザクションに含まれる資金は、プロトコルに違反している参加者に完全に帰属するため、 そこからの支払いに関する情報を外部委託してもセキュリティ上のリスクはありません。） ↩