05-onchain-ja.md

BOLT #5: オンチェーン取引処理の推奨事項

概要

Lightning は、2 つの当事者（ローカルノードとリモートノード）がオフチェーンで取引を行うことを可能にします。これにより、各当事者に相互署名されたコミットメントトランザクションが与えられ、チャネルの現在の状態（基本的には現在の残高）を記述します。このコミットメントトランザクションは、新しい支払いが行われるたびに更新され、常に使用可能です。

チャネルが終了する方法は 3 つあります：

1. 良い方法（相互クローズ）：ある時点でローカルノードとリモートノードがチャネルを閉じることに合意します。彼らはクローズトランザクション（コミットメントトランザクションに似ていますが、保留中の支払いはありません）を生成し、それをブロックチェーンに公開します（BOLT #2: Channel Close を参照）。
2. 悪い方法（一方的クローズ）：何かがうまくいかず、どちらの側にも悪意がない可能性があります。例えば、一方の当事者がクラッシュしたかもしれません。一方が最新のコミットメントトランザクションを公開します。
3. 醜い方法（取り消されたトランザクションクローズ）：一方の当事者が故意に不正を試み、古いコミットメントトランザクションを公開します（おそらく、以前のバージョンで、より有利なものです）。

Lightning は信頼を必要としないように設計されているため、これらの 3 つのケースのいずれにおいても資金を失うリスクはありません。ただし、状況が適切に処理されることが条件です。この文書の目的は、上記の状況にオンチェーンで遭遇したときにノードがどのように反応すべきかを正確に説明することです。

目次

• 一般的な命名法
• コミットメントトランザクション
• チャネルの失敗
• 相互クローズの処理
• 一方的クローズの処理：ローカルコミットメントトランザクション
  • HTLC 出力の処理：ローカルコミットメント、ローカルオファー
  • HTLC 出力の処理：ローカルコミットメント、リモートオファー
• 一方的クローズの処理：リモートコミットメントトランザクション
  • HTLC 出力の処理：リモートコミットメント、ローカルオファー
  • HTLC 出力の処理：リモートコミットメント、リモートオファー
• 取り消されたトランザクションクローズの処理
  • ペナルティトランザクションの重量計算
• HTLC トランザクションの生成
• 一般的な要件
• 付録 A: 期待される重量
  • to_local ペナルティトランザクションの証人の期待される重量
  • offered_htlc ペナルティトランザクションの証人の期待される重量
  • accepted_htlc ペナルティトランザクションの証人の期待される重量
• 著者

一般的な命名法

未使用のアウトプットは 未解決 と見なされ、このドキュメントで詳述されているように 解決 されます。通常、これは別の 解決 トランザクションでそれを使用することによって達成されます。ただし、時には後でウォレットで使用するためにアウトプットを記録しておくだけで十分な場合もあり、その場合、アウトプットを含むトランザクション自体が 解決 トランザクションと見なされます。

解決 されたアウトプットは、リモートの 解決 トランザクションが最も作業量の多いブロックチェーンで少なくとも 100 ブロック深く含まれたときに 不可逆的に解決 されたと見なされます。100 ブロックは、最も長い既知のビットコインフォークよりもはるかに長く、マイナーの報酬の確認に使用される待ち時間と同じです（Reference Implementationを参照）。

要件

ノードは：

• 資金調達トランザクションをブロードキャストした場合、または HTLC アウトプットを含むコミットメントトランザクションのコミットメント署名を送信した場合：
  • すべてのアウトプットが 不可逆的に解決 されるまで：
    • 不可逆的に解決 されていないアウトプットを消費するトランザクションをブロックチェーンで監視しなければなりません。
• 以下に指定されているように、すべてのアウトプットを 解決 しなければなりません。
• ブロックチェーンの再編成が発生した場合に備えて、アウトプットを複数回解決する準備をしておかなければなりません。
• 資金調達トランザクションが消費された場合、チャネルがすでに閉じられていない場合：
  • 説明的な error を送信してもかまいません。
  • チャネルを失敗させるべきです。
• 無効なトランザクションを無視するべきです。

理論的根拠

ローカルノードがいくらかの資金を賭けている場合、リモートノードが一方的に閉じないようにするためにブロックチェーンを監視する必要があります。

無効なトランザクション（例えば、悪い署名）は誰でも生成できます（そしてブロックチェーンによって無視されます）が、それらは何らかのアクションを引き起こすべきではありません。

コミットメントトランザクション

ローカルおよびリモートノードはそれぞれ コミットメントトランザクション を保持しています。これらのコミットメントトランザクションには最大で 6 種類のアウトプットがあります：

1. ローカルノードのメインアウトプット：ゼロまたは 1 つのアウトプットで、ローカルノード の delayed_pubkey に支払います。
2. リモートノードのメインアウトプット：ゼロまたは 1 つのアウトプットで、リモートノード の delayed_pubkey に支払います。
3. ローカルノードのアンカーアウトプット：1 つのアウトプットで、ローカルノード の funding_pubkey に支払います。
4. リモートノードのアンカーアウトプット：1 つのアウトプットで、リモートノード の funding_pubkey に支払います。
5. ローカルノードが提供する HTLCs：ゼロまたは複数の保留中の支払い (HTLCs) で、支払いのプレイメージと引き換えに リモートノード に支払います。
6. リモートノードが提供する HTLCs：ゼロまたは複数の保留中の支払い (HTLCs) で、支払いのプレイメージと引き換えに ローカルノード に支払います。

ローカルノードとリモートノードが協力するようにインセンティブを与えるために、OP_CHECKSEQUENCEVERIFY 相対タイムアウトが ローカルノードの出力（ローカルノードのコミットメントトランザクション内）と リモートノードの出力（リモートノードのコミットメントトランザクション内）に課されます。たとえば、ローカルノードがそのコミットメントトランザクションを公開した場合、自分の資金を請求するために待つ必要がありますが、リモートノードは自分の資金に即座にアクセスできます。その結果、2つのコミットメントトランザクションは同一ではありませんが、（通常）対称的です。

詳細は BOLT #3: Commitment Transaction を参照してください。

チャネルの失敗

チャネルを閉じる方法はいくつかありますが、最も効率的な方法が推奨されます。

さまざまなエラーケースがチャネルを閉じることに関与します。ピアにエラーメッセージを送信するための要件は BOLT #1: The error Message に指定されています。

要件

ノードは以下を行います：

• ローカルコミットメントトランザクションが to_local または HTLC 出力を一度も含んでいない場合：
  • チャネルを単に忘れてもかまいません。
• それ以外の場合：
  • 現在のコミットメントトランザクションが to_local または他の HTLC 出力を含んでいない場合：
    • リモートノードがチャネルを閉じるのを単に待ってもかまいません。
    • リモートノードが閉じるまで：
      • チャネルを忘れてはなりません。
  • それ以外の場合：
    • 十分な手数料を含む有効な closing_signed メッセージを受け取った場合：
      • この手数料を使用して 相互クローズ を行うべきです。
    • それ以外の場合：
      • ノードがチャネルの状態が古いと知っているか、そう仮定している場合：
        • 最後のコミットメントトランザクションをブロードキャストしてはなりません。
      • それ以外の場合：
        • 最後のコミットメントトランザクションを、署名を持っているものをブロードキャストして 一方的クローズ を行わなければなりません。
        • 十分な手数料を提供して to_local_anchor 出力を使い、コミットメントトランザクションをブロックに含めるインセンティブを与えなければなりません。第三者に支払う際には特に注意が必要です。これは、非アンカー出力に CSV 遅延を追加することで対処された脆弱性を再導入することになるからです。
        • 取引がブロックに迅速に含まれるのに不十分である場合、replace-by-fee または他のメカニズムを使用するべきです。

理由

dust_limit_satoshis は非経済的なアウトプットの作成を防ぐためのものであり（そうでなければブロックチェーン上で永遠に未使用のまま残ってしまいます）、すべてのコミットメントトランザクションのアウトプットは消費されなければなりません。

チャネルの初期段階では、一方がチャネル内にほとんどまたは全く資金を持たないことが一般的です。この場合、リスクがないため、ノードはチャネルの状態を監視するためのリソースを消費する必要はありません。

相互クローズは一方的なクローズよりも好まれる傾向があります。なぜなら、前者のアウトプットは遅延によって制約されず、ウォレットによって直接消費可能だからです。さらに、相互クローズの手数料はコミットメントトランザクションの手数料（または option_anchors の場合、コミットメントトランザクションがマイニングされるために子トランザクションを必要とするかもしれません）よりも誇張されることが少ない傾向があります。したがって、closing_signed の署名を使用しない唯一の理由は、提示された手数料が処理されるには小さすぎる場合です。

相互クローズの処理

クローズトランザクションはファンディングトランザクションのアウトプットを解決します。

相互クローズの場合、ノードは他に何もする必要はありません。すでに合意したアウトプットが指定された scriptpubkey に送信されるからです（BOLT #2: クローズの開始: shutdownを参照）。

一方的なクローズの処理：ローカルコミットメントトランザクション

これは一方的なクローズに関する二つのケースのうちの一つです。この場合、ノードは自分のローカルコミットメントトランザクションを発見し、それがファンディングトランザクションのアウトプットを解決します。

しかし、ノードは一方的なクローズを開始した場合、そのアウトプットから資金を取得することはできません。OP_CHECKSEQUENCEVERIFY の遅延が経過するまでは（リモートノードの to_self_delay フィールドで指定されています）。関連する場合、この状況は以下に記載されています。

要件

ノードは以下を行います：

• ローカルコミットメントトランザクションを発見した場合：
  • to_local アウトプットを便利なアドレスに消費するべきです。
  • OP_CHECKSEQUENCEVERIFY の遅延が経過するまで（リモートノードの to_self_delay フィールドで指定されています）アウトプットを消費してはいけません。
    • 注：アウトプットが消費された場合（推奨されるように）、そのアウトプットは消費トランザクションによって解決されます。そうでなければ、コミットメントトランザクション自体によって解決されたと見なされます。
  • to_remote アウトプットを無視してもかまいません。
    • 注：ローカルノードによるアクションは不要です。to_remote はコミットメントトランザクション自体によって解決されたと見なされます。
  • 自分自身によって提供された HTLC を以下に指定されたように処理しなければなりません：HTLC Output Handling: Local Commitment, Local Offers。
  • リモートノードによって提供された HTLC を以下に指定されたように処理しなければなりません：HTLC Output Handling: Local Commitment, Remote Offers。

根拠

to_local 出力を使うことで、後で使うために特定のチャネルに関連付けられた複雑な証人スクリプトを覚えておく必要がなくなります。

to_remote 出力は完全にリモートノードの問題であり、無視してかまいません。

HTLC 出力の処理：ローカルコミットメント、ローカルオファー

各 HTLC 出力は、ローカルオファー者 がタイムアウト後に HTLC-timeout トランザクションを使用して消費するか、リモート受取人 が支払いプレイメージを持っている場合にのみ消費できます。

HTLC は、ダストとしてトリミングされたか、トランザクションが部分的にしかコミットされていないため、出力として表されない場合があります。

HTLC 出力は、最新のブロックの高さが HTLC cltv_expiry 以上になったときに タイムアウト します。

要件

ノードは以下を行います：

• コミットメントトランザクションの HTLC 出力が支払いプレイメージを使用して消費された場合、その出力は 不可逆的に解決された と見なされます：
  • トランザクション入力証人から支払いプレイメージを抽出しなければなりません。
• コミットメントトランザクションの HTLC 出力が タイムアウト し、解決 されていない場合：
  • HTLC-timeout トランザクションを使用して出力を 解決 しなければなりません。
  • 解決トランザクションが適切な深さに達したら：
    • 対応する受信 HTLC（ある場合）を失敗させなければなりません。
    • その HTLC-timeout トランザクションの出力を解決しなければなりません。
    • HTLC-timeout トランザクションを便利なアドレスに送金して解決することを推奨します。
      • 注：出力が消費された場合（推奨されるように）、出力は消費トランザクションによって 解決 されます。そうでない場合は、HTLC-timeout トランザクション自体によって 解決 されたと見なされます。
    • OP_CHECKSEQUENCEVERIFY の遅延が経過するまで待たなければなりません（リモートノードの open_channel to_self_delay フィールドで指定されているように）その HTLC-timeout 出力を消費する前に。
• このコミットメントトランザクションに出力がないコミットされた HTLC について：
  • コミットメントトランザクションが適切な深さに達したら：
    • 対応する受信 HTLC（ある場合）を失敗させなければなりません。
  • HTLC に対応する出力を含む 有効な コミットメントトランザクションがない場合。
    • 対応する受信 HTLC を早めに失敗させてもかまいません。

理論的根拠

支払いのプレイメージは、支払いを証明するため（提供ノードが支払いを開始した場合）または別のピアからの対応する受信 HTLC を引き換えるため（提供ノードが支払いを転送している場合）に使用されます。ノードが支払いを抽出した後は、HTLC を消費するトランザクション自体の運命には関心がなくなります。

両方の解決が可能な場合（例えば、ノードがタイムアウト後に支払い成功を受け取った場合）、どちらの解釈も受け入れられます。この場合、受取人がそれが発生する前に消費する責任があります。

ローカル HTLC タイムアウトトランザクションは、リモートノードがそれを履行して資金を請求するのを防ぐために、HTLC をタイムアウトさせるために使用する必要があります。その後、ローカルノードは対応する受信 HTLC を update_fail_htlc（おそらく理由は permanent_channel_failure）を使用してバックフェイルできます。詳細は BOLT #2 に記載されています。受信 HTLC もオンチェーンにある場合、ノードは単にタイムアウトを待つ必要があります。早期失敗を通知する方法はありません。

HTLC が いかなるコミットメントトランザクション にも現れないほど小さい場合、それは即座に安全に失敗させることができます。そうでない場合、HTLC が ローカルコミットメントトランザクション に含まれていない場合、ノードはブロックチェーンの再編成や競争が、ノードがそれを失敗させる前に HTLC を含むコミットメントトランザクションに切り替わらないように確認する必要があります（したがって待機が必要です）。受信 HTLC がそのタイムアウト前に失敗する必要があるという要件は、上限として依然として適用されます。

HTLC 出力処理：ローカルコミットメント、リモートオファー

各 HTLC 出力は、受取人が支払いのプレイメージを持っている場合にのみ、HTLC 成功トランザクションを使用して消費できます。プレイメージを持っていない場合（そしてそれを発見しない場合）、オファー側がタイムアウト後に HTLC 出力を消費する責任があります。

提供された HTLC にはいくつかの可能性があります：

1. オファー側がそれに対して不可逆的にコミットしていない。受取人は通常、プレイメージを知らないでしょう。なぜなら、完全にコミットされるまで HTLC を転送しないからです。したがって、プレイメージを使用すると、この受取人が最終ホップであることが明らかになります。この場合、HTLC をタイムアウトさせるのが最善です。
2. オファー側が提供された HTLC に対して不可逆的にコミットしているが、受取人がまだ送信 HTLC にコミットしていない。この場合、受取人は提供された HTLC を転送するかタイムアウトさせることができます。
3. 受取人が提供された HTLC と引き換えに送信 HTLC にコミットしている。この場合、受取人は送信 HTLC からプレイメージを受け取ったらそれを使用しなければなりません。そうしないと、受信支払いを引き換えずに送信支払いを送信することで資金を失うことになります。

要件

ローカルノード：

• 未解決の HTLC 出力に対して、支払いのプレイメージを受け取った（または既に持っている）場合で、かつ送信 HTLC にコミットしている場合：
  • HTLC-success トランザクションを使用して、それを消費することで出力を解決しなければなりません。
  • 自分が最終受取人でない場合、自分のプレイメージを公開してはなりません。^{Preimage-Extraction}
  • その HTLC-success トランザクションの出力を解決しなければなりません。
• それ以外の場合：
  • リモートノードが HTLC に対して不可逆的にコミットしていない場合：
    • それを消費することで出力を解決してはなりません。
• その HTLC-success トランザクションの出力を、便利なアドレスに消費することで解決するべきです。
• OP_CHECKSEQUENCEVERIFY の遅延が経過するまで待たなければなりません（リモートノードの open_channel の to_self_delay フィールドで指定されている通り）、その HTLC-success トランザクションの出力を消費する前に。

出力が消費された場合（推奨されるように）、消費トランザクションによって出力が解決されます。そうでない場合は、HTLC-success トランザクション自体によって解決されたと見なされます。

他に解決されない場合、HTLC 出力が期限切れになると、それは不可逆的に解決されたと見なされます。

一方的なクローズ処理：リモートコミットメントトランザクション

リモートノードのコミットメントトランザクションは、資金トランザクションの出力を解決します。

この場合、ノードの動作を制約する遅延はないため、ローカルコミットメントトランザクションを発見した場合よりもノードにとって扱いやすいです（一方的なクローズ処理：ローカルコミットメントトランザクションを参照）。

要件

ローカルノード：

• リモートノードによってブロードキャストされた有効なコミットメントトランザクションを発見した場合：
  • 可能であれば：
    • 以下に指定された通りに各出力を処理しなければなりません。
    • 関連する to_remote に関しては、何も行わなくてもよいです。これは単にローカルノードへの P2WPKH 出力です。
      • 注：to_remote はコミットメントトランザクション自体によって解決されたと見なされます。
    • 関連する to_local に関しては、何も行わなくてもよいです。これはリモートノードへの支払い出力です。
      • 注：to_local はコミットメントトランザクション自体によって解決されたと見なされます。
    • 自分自身が提供した HTLC を HTLC 出力処理：リモートコミットメント、ローカルオファー に指定された通りに処理しなければなりません。
    • リモートノードが提供した HTLC を HTLC 出力処理：リモートコミットメント、リモートオファー に指定された通りに処理しなければなりません。
  • それ以外の場合（何らかの理由でブロードキャストを処理できない場合）：
    • 潜在的に失われた資金についてユーザに通知しなければなりません。

理論的根拠

commitment_signed を通じて署名が受け取られた後、対応する revoke_and_ack の前に、複数の有効な 未取り消し のコミットメントトランザクションが存在する可能性があります。そのため、どちらのコミットメントも リモートノード のコミットメントトランザクションとして機能する可能性があり、ローカルノードは両方を処理する必要があります。

データ損失が発生した場合、ローカルノードは リモートノード のすべてのコミットメントトランザクションの HTLC 出力を認識できない状態に達することがあります。これは、トランザクションに署名しており、コミットメント番号が予想より大きいことからデータ損失状態を検出できます。トランザクションのために自分の remotepubkey を導き出し、自分の資金を回収することができます。注意：このシナリオでは、ノードは HTLC を回収することができません。

HTLC 出力の処理：リモートコミットメント、ローカルオファー

各 HTLC 出力は、タイムアウト後に ローカルオファー者 によって、または支払いプレイメージを持っている場合に HTLC 成功トランザクションを使用して リモート受取人 によってのみ消費されます。

出力がダストとしてトリムされたため、またはリモートノードが異なる HTLC を持つ 2 つの 有効な コミットメントトランザクションを持っているため、出力で表されていない HTLC が存在することがあります。

HTLC 出力は、最新のブロックの深さが HTLC cltv_expiry 以上になったときに タイムアウト します。

要件

ローカルノードは：

• コミットメントトランザクションの HTLC 出力が支払いプレイメージを使用して消費された場合：
  • HTLC 成功トランザクションの入力証人から支払いプレイメージを抽出しなければなりません。
    • 注意：出力は 不可逆的に解決された と見なされます。
• コミットメントトランザクションの HTLC 出力が タイムアウト し、解決 されていない場合：
  • 出力を便利なアドレスに送金して 解決 しなければなりません。
• このコミットメントトランザクションに出力がないコミットされた HTLC に対して：
  • コミットメントトランザクションが適切な深さに達したら：
    • 対応する受信 HTLC（ある場合）を失敗させなければなりません。
  • そうでない場合：
    • 有効な コミットメントトランザクションに HTLC に対応する出力が含まれていない場合：
      • 早めに失敗させてもかまいません。

根拠

コミットメントトランザクションがリモートノードに属する場合、HTLC出力を支出する唯一の方法（支払いプレイメージを使用する）は、HTLC-successトランザクションを使用することです。

支払いプレイメージは、支払いの証明として機能するか（提供ノードが支払いの発信者である場合）、別のピアからの対応する受信HTLCを引き換えるために使用されます（提供ノードが支払いを転送している場合）。ノードが支払いを受け取った後は、HTLC支出トランザクション自体の運命を気にする必要はありません。

両方の解決策が可能な場合（例：ノードがタイムアウト後に支払い成功を受け取る場合）、どちらの解釈も受け入れられます。受取人がこれが発生する前にそれを支出する責任があります。

タイムアウトした後、ローカルノードはHTLC-successトランザクションをリモートノードが使用するのを防ぐために、HTLC出力を支出する必要があります。その後、対応する受信HTLCをupdate_fail_htlc（おそらく理由はpermanent_channel_failure）を使用してバックフェイルできます。詳細はBOLT #2に記載されています。 受信HTLCがオンチェーンにある場合、ノードは単にタイムアウトを待ちます。早期失敗を通知する方法がないためです。

HTLCがいかなるコミットメントトランザクションにも現れないほど小さい場合、それは即座に安全に失敗させることができます。そうでない場合、HTLCがローカルコミットメントトランザクションにない場合、ノードはブロックチェーンの再編成や競争がそれを含むコミットメントトランザクションに切り替わらないことを確認する必要があります。そのため、待機が必要です。受信HTLCが自身のタイムアウト前に失敗する必要があるという要件は、上限として依然として適用されます。

HTLC出力の処理：リモートコミットメント、リモートオファー

リモートHTLC出力は、ローカルノードが支払いプレイメージを持っている場合にのみ支出できます。ローカルノードがプレイメージを持っていない（または発見しない）場合、HTLC出力がタイムアウトした後にそれを支出するのはリモートノードの責任です。

提供されたHTLCには実際にいくつかの可能性があります：

1. 提供者がそれに対して不可逆的にコミットしていない。この場合、受取人は通常プレイメージを知らないでしょう。HTLCが完全にコミットされるまで転送しないからです。プレイメージを使用すると、この受取人が最終ホップであることが明らかになるため、HTLCがタイムアウトするのを許すのが最善です。
2. 提供者が提供されたHTLCに対して不可逆的にコミットしているが、受取人がまだ送信HTLCにコミットしていない。この場合、受取人はそれを転送するか、タイムアウトを待つことができます。
3. 受取人が提供されたHTLCと引き換えに送信HTLCにコミットしている。この場合、受取人は送信HTLCからプレイメージを受け取った場合、それを使用しなければなりません。そうでなければ、受信支払いを引き換えずに送信支払いを送ることで資金を失うことになります。

要件

ローカルノード：

• 未解決の HTLC 出力に対して、支払いのプレイメージを受け取った（または既に持っている）場合で、かつ送信 HTLC にコミットしている場合：
  • 出力を便利なアドレスに送金することで解決しなければなりません。
• それ以外の場合：
  • リモートノードが HTLC に対して不可逆的にコミットしていない場合：
    • 出力を送金することで解決してはいけません。

他に解決されない場合、HTLC 出力が期限切れになると、それは不可逆的に解決されたと見なされます。

取り消されたトランザクションのクローズ処理

もし任意のノードが古いコミットメントトランザクション（最新のもの以外の以前のコミットメントトランザクション）をブロードキャストして不正を試みた場合、チャネルのもう一方のノードは取り消し秘密鍵を使用して、チャネルの元の資金調達トランザクションからすべての資金を請求できます。

要件

ノードが自分の取り消し秘密鍵を持つコミットメントトランザクションを発見した場合、資金調達トランザクションの出力は解決されます。

ローカルノード：

• 自分が per_commitment_secret を公開したコミットメントトランザクションをブロードキャストしてはいけません。
• ローカルノードのメイン出力 に関しては、何も行わなくてもよいです。これは自分自身への単純な P2WPKH 出力です。
  • 注：この出力はコミットメントトランザクション自体によって解決されたと見なされます。
• 取り消し秘密鍵を使用して、リモートノードのメイン出力 を解決しなければなりません。
• リモートノードの提供した HTLC を次のいずれかの方法で解決しなければなりません：
  • 支払い取り消し秘密鍵を使用してコミットメント tx を送金する。
  • 支払いプレイメージを使用してコミットメント tx を送金する（既知の場合）。
  • リモートノードが公開した場合、HTLC-timeout tx を送金する。
• ローカルノードの提供した HTLC を次のいずれかの方法で解決しなければなりません：
  • 支払い取り消し秘密鍵を使用してコミットメント tx を送金する。
  • HTLC のタイムアウトが過ぎた後にコミットメント tx を送金する。
  • リモートノードが公開した場合、HTLC-success tx を送金する。
• 取り消し秘密鍵を使用して、リモートノードの HTLC-timeout トランザクション を解決しなければなりません。
• 取り消し秘密鍵を使用して、リモートノードの HTLC-success トランザクション を解決しなければなりません。
• 既に知られていない場合、トランザクション入力の証人から支払いプレイメージを抽出するべきです。
• option_anchors が適用される場合：
  • 単一のトランザクションを使用してすべての出力を解決してもよいです。
  • 期限から security_delay ブロックに達する前に確認が行われない場合：
    • 取り消された出力をそれぞれの独立したペナルティトランザクションで解決するべきです。複数の取り消された出力を一度に請求する以前のペナルティトランザクションは、トランザクションピンニング攻撃によって確認が妨げられる可能性があります。
• それ以外の場合：
  • 単一のトランザクションを使用してすべての出力を解決してもよいです。
• HTLC トランザクションによって無効化されるトランザクションを処理しなければなりません。

理論的根拠

すべての出力を解決する単一のトランザクションは、各パーティーあたり 483 HTLC の制限（BOLT #2 を参照）により、標準サイズの制限内に収まります。

注意: option_anchors が適用される場合、不正行為を行うノードは SIGHASH_SINGLE の可鍛性を利用して、その HTLC-timeout/HTLC-success 出力の支出を固定できます。このため、すべての取り消された出力に対して単一のペナルティトランザクションを使用することは安全ではありません。これは、ローカルノードの to_local 出力 の相対ロックタイムが満了するまで伝播を妨げられ、不正行為を行ったパーティーがこの出力に対するペナルティを逃れる可能性があるためです。ただし、この状況は、固定トランザクションが確認された場合に、第二レベルの取り消された出力に対する正当な罰を妨げるものではありません。

security_delay は、取り消された出力の絶対期限に対する固定ポイントであり、罰を与えるノードが取り消された出力に対して単一支出トランザクションをブロードキャストし、その確認が完了するまで積極的に手数料を引き上げる必要があります。security_delay の正確な値はノードポリシーに委ねられていますが、18 ブロック（受信 HTLC の締切に類似）を推奨します。

ペナルティトランザクションの重量計算

ペナルティトランザクションには 3 つの異なるスクリプトがあり、それぞれの証跡重量は以下の通りです（重量計算の詳細は 付録 A にあります）：

to_local_penalty_witness: 160 bytes
offered_htlc_penalty_witness: 243 bytes
accepted_htlc_penalty_witness: 249 bytes

ペナルティ txinput 自体は 41 バイトを占め、重量は 164 バイトです。これにより、各入力の重量は次のようになります：

to_local_penalty_input_weight: 324 bytes
offered_htlc_penalty_input_weight: 407 bytes
accepted_htlc_penalty_input_weight: 413 bytes

ペナルティトランザクションの残りは、4+1+1+8+1+34+4=53 バイトの非証跡データを占めます。これは、2 バイトの証跡ヘッダーに加えて、支払い先の証跡スクリプトハッシュ（最大の標準出力スクリプト）を持つと仮定します。

これらの出力を支出することに加えて、ペナルティトランザクションはオプションでコミットメントトランザクションの to_remote 出力を支出することができます（例：手数料として支払われる総額を減らすため）。これを行うには、P2WPKH 証跡と追加の txinput を含める必要があり、追加で 108 + 164 = 272 バイトが必要です。

最悪のシナリオでは、ノードは受信 HTLC のみを保持し、HTLC-timeout トランザクションが公開されず、ノードがコミットメントトランザクションから支出することを余儀なくされます。

標準の最大重量が 400000 バイトの場合、単一のトランザクションでスイープできる HTLC の最大数は次のとおりです：

max_num_htlcs = (400000 - 324 - 272 - (4 * 53) - 2) / 413 = 966

したがって、483 の双方向 HTLC（to_local と to_remote 出力を含む）を単一のペナルティトランザクションで解決できます。注意：to_remote 出力がスイープされない場合でも、結果として得られる max_num_htlcs は 967 であり、483 HTLC の同じ一方向制限をもたらします。

HTLC トランザクションの生成

option_anchors がコミットメントトランザクションに適用されない場合、HTLC-timeout および HTLC-success トランザクションは完全なトランザクションであり、（うまくいけば！）合理的な手数料を持ち、直接使用する必要があります。

それ以外の場合、SIGHASH_SINGLE|SIGHASH_ANYONECANPAY をピアから受け取った HTLC 署名に使用しなければなりません。これにより、HTLC トランザクションを他のトランザクションと組み合わせることができます。ローカル署名は SIGHASH_ALL を使用しなければなりません。そうでないと、誰でも追加の入力と出力をトランザクションに添付できてしまいます。

option_anchors が適用される場合、HTLC-timeout および HTLC-success トランザクションは、入力と出力が同じ値を持つように署名されます。これは手数料がゼロであり、合理的な手数料に達するために他の入力と組み合わせなければなりません。

要件

コミットメントトランザクションのために HTLC-success または HTLC-timeout トランザクションをブロードキャストするノード：

• option_anchors が適用される場合：
  • ブロックに迅速に含まれるために十分な手数料を提供する入力と組み合わせなければなりません。
  • 他のトランザクションと組み合わせてもかまいません。

一般的な要件

ノード：

• 資金調達トランザクション出力を消費するトランザクションを発見した場合、上記のカテゴリ（相互クローズ、単独クローズ、または取り消されたトランザクションクローズ）に該当しない場合：
  • 潜在的に失われた資金についてユーザに警告しなければなりません。
    • 注意：そのような不正トランザクションの存在は、その秘密鍵が漏洩し、その結果として資金が失われる可能性があることを示唆しています。
• 単に最も作業量の多いチェーンの内容をトランザクションのために監視してもかまいません。
  • 注意：オンチェーン HTLC は十分にまれであるべきであり、速度を重要視する必要はありません。
• （有効な）ブロードキャストトランザクション（いわゆるメモリプール）を監視してもかまいません。
  • 注意：メモリプールトランザクションを監視することで、HTLC の引き出しの遅延が低くなるはずです。

Appendix A: Expected Weights

to_local ペナルティトランザクションの証明書の期待ウェイト

BOLT #3 で説明されているように、このトランザクションの証明書は以下の通りです：

<sig> 1 { OP_IF <revocationpubkey> OP_ELSE to_self_delay OP_CSV OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG }

to_local ペナルティトランザクションの証明書の期待ウェイトは次のように計算されます：

to_local_script: 83 bytes
    - OP_IF: 1 byte
        - OP_DATA: 1 byte (revocationpubkey length)
        - revocationpubkey: 33 bytes
    - OP_ELSE: 1 byte
        - OP_DATA: 1 byte (delay length)
        - delay: 8 bytes
        - OP_CHECKSEQUENCEVERIFY: 1 byte
        - OP_DROP: 1 byte
        - OP_DATA: 1 byte (local_delayedpubkey length)
        - local_delayedpubkey: 33 bytes
    - OP_ENDIF: 1 byte
    - OP_CHECKSIG: 1 byte

to_local_penalty_witness: 160 bytes
    - number_of_witness_elements: 1 byte
    - revocation_sig_length: 1 byte
    - revocation_sig: 73 bytes
    - one_length: 1 byte
    - witness_script_length: 1 byte
    - witness_script (to_local_script)

offered_htlc ペナルティトランザクションの証明書の期待ウェイト

offered_htlc ペナルティトランザクションの証明書の期待ウェイトは次のように計算されます（いくつかの計算はすでに BOLT #3 で行われています）：

offered_htlc_script: 133 bytes

offered_htlc_penalty_witness: 243 bytes
    - number_of_witness_elements: 1 byte
    - revocation_sig_length: 1 byte
    - revocation_sig: 73 bytes
    - revocation_key_length: 1 byte
    - revocation_key: 33 bytes
    - witness_script_length: 1 byte
    - witness_script (offered_htlc_script)

accepted_htlc ペナルティトランザクションの証明書の期待ウェイト

accepted_htlc ペナルティトランザクションの証明書の期待ウェイトは次のように計算されます（いくつかの計算はすでに BOLT #3 で行われています）：

accepted_htlc_script: 139 bytes


accepted_htlc_penalty_witness: 249 バイト
    - number_of_witness_elements: 1 バイト
    - revocation_sig_length: 1 バイト
    - revocation_sig: 73 バイト
    - revocationpubkey_length: 1 バイト
    - revocationpubkey: 33 バイト
    - witness_script_length: 1 バイト
    - witness_script (accepted_htlc_script)

著者

[FIXME:]

この作品は Creative Commons Attribution 4.0 International License の下でライセンスされています。