The Bitcoin Lightning Network: Scalability Off-Chain Instant Payments

著：Joseph Poon, Thaddeus Dryja

Abstract

Bitcoin プロトコルは、単一の管理第三者が資金を保有したり、ブロードバンド接続を使用するコンピュータ以上のものを参加者に要求したりする必要はなく、今日の全ての電子決済システムにおける世界的な金融トランザクション量を含んでいる。非中央集権システムが提案され、それによってトランザクションはオフブロックチェーンで価値の転送が行われるマイクロペイメントチャネルのネットワーク上で送られる。

1. The Bitcoin Blockchain Scalability Problem

Bitcoin ブロックチェーンは分散台帳の素晴らしい可能性を秘めているが、支払いプラットフォームとしてはそれ自身は近い将来いつでも世界の商取引をカバーできない。ブロックチェーンはゴシッププロトコルであるため、台帳のステート修正は全ての参加者にブロードキャストしなけれなばならない。もし、Bitcoin ネットワークの各ノードが世界的に発生した全ての単一トランザクションを知らなければならない場合、全てのトランザクションを網羅するネットワークの能力に大きな抵抗を作る可能性がある。分散化やネットワークが提供するセキュリティを犠牲にせずそれを実現することが望ましい。

2013 年における Visa のピーク時のトランザクション量は毎秒 47,000 Tx であった。これを Bitcoin で実現しようとすると、単一ブロックのサイズは 8 GB になり、1日で 400 TB のデータが蓄積していく事になる。帯域幅やストレージ容量の観点から Visa のような能力に達することは今日では非現実的である。Bitcoin が将来全ての電子支払いを置き換えたとしたら、Bitcoin ネットワークの崩壊または極度の集中化を起こしているだろう。この中央集権化は Bitcoin が台帳の正確さとセキュリティを保証することを可能にする分散化を破ることになる。

Bitcoin を使用して1秒あたり 47,000 をはるかに超えるトランザクションを実現するには、Bitcoin ブロックチェーン自体からトランザクションを切り離して実行する必要がある。Bitcoin ネットワークがマイクロペイメントの手数料が非常に低く、1秒あたりのトランザクション数をほぼ無制限にサポートしている場合はさらに良い。多くのマイクロペイメントは任意の大きさの支払いを連続で二者間で可能にすることができる。マイクロペイメントを実現するには、グローバルな Bitcoin ブロックチェーンでブロードキャストされるトランザクションの量を著しく減らす必要がある。

2. A Network of Micropayment Channels Can Solve Scalability

ブロックチェーンでは、2人の参加者だけが毎日の定期的なトランザクションに関心がある場合、ネットワーク内の他のすべてのノードがそのトランザクションについて知っている必要はない。代わりに、最低限の情報のみをブロックチェーンに含めることが好ましい。すべてのトランザクションについて全世界に伝えるのを遅らせることにより、後日関係の正味の決済を行うことで、ユーザーは、ブロックチェーンを膨らませたり、一元的なカウンターパーティに信頼を築いたりすることなく、多くのトランザクションを実行できる。トラストレスな構造はグローバルコンセンサスの要素としてタイムロックを使用することで達成することができる。

現在のマイクロペイメントとスケーラビリティの解決策は、管理者にトランザクションやコインの管理を任せることである。（中央集権化が加速する）

代わりに、マイクロペイメントチャネルを使用して Bitcoin は今日のデスクトップ PC の計算力で数十億 tps にスケールすることができる。マイクロペイメントチャネル内に多くの支払いを送ることで、分散的方法で大きな量の資産を他のパーティに送ることができる。これらのチャネルは Bitcoin 上の分離したトラストネットワークではなく、現実の Bitcoin トランザクションである。マイクロペイメントチャネルは永久的に残高を更新するために二者間で関係を作り、1つのトランザクションでブロックチェーンにブロードキャストされるものを延期して、2つのパーティ間の合計残高を相殺する。マイクロペイメントチャネルは現実の Bitcoin トランザクションを使用し、両方の当事者がブロックチェーン上の現在の残高を保証できるような方法でブロードキャストをブロックチェーンに延期することのみを選択する。

2.1 Micropayment Channels Do Not Require Trust

もし、両者のカウンターパーティがチャネル内の現在の残高を 0.07 BTC をアリスが持ち、0.03 BTC をボブが持っていると合意していれば、それが正しい残高である。もし、チャネル内の残高がアリス、ボブともに 0.05 BTC であり、トランザクション後の残高がそれぞれ 0.07 BTC と 0.03 BTC であるとする。ネットワークはどちらの残高が正しいのかを知る必要がある。ブロックチェーントランザクションはブロックチェーン台帳をタイムスタンプシステムとして使用することでこの問題を解決する。同時に、ネットワークにとってコストがかかるため絶対的に必要にならない限り、このタイムスタンプシステムを頻繁に使用しないシステムを作ることが望ましい。

代わりに、両者がトランザクションに署名し、ブロードキャストしないことにコミットすることができる。つまり、アリスとボブが 2-of-2 マルチシグネチャアドレス（資産を使用するためには両者の合意が必要なアドレス）に資産を入れるとコミットすると、現在の残高状況に賛成することができる。アリスとボブはこのアドレスから彼ら自身に 0.05 BTC を払い戻すために合意することができる。この払い戻しはブロックチェーンにブロードキャストされない。どちらの当事者もそうすることができるが、代わりにその取引を保留することを選択することができる。このトランザクションのブロードキャストを延期することによって、彼らはこの残高を将来変更することを選択する可能性がある。残高を更新するために、両者はマルチシグネチャアドレスから新しい支出を作る。ただし、適切な設計がなければ、（新しい支出と元の払い戻し）どの支出が正しいかわからないというタイムスタンプの問題がある。

しかし、タイムスタンプと日程の制約は Bitcoin ブロックチェーンのような、全てのトランザクションの順序ののように複雑ではない。マイクロペイメントチャネルの場合、2つの状態のみ必要とされている。現在の正しい残高と古い非推奨の残高である。正しい現在の残高は1つだけであり、廃止された古い残高も多数ある可能性がある。従って、Bitcoin においてスクリプトを考案することは可能であり、全ての古いトランザクションは無効で新しいトランザクションのみが有効である。無効にすることは Bitcoin アウトプットスクリプトと他のパーティに彼らの全ての資産をチャネルカウンターパーティに与えることを強いる依存トランザクションによって強制される。すべての資金をペナルティとして他に与えることにより、古いトランザクションはすべて無効になる。

この無効プロセスは両者が現在の台帳状態に合意すればチャネルコンセンサスプロセスを通して存続することができる。残高はどちらかが合意しなかった場合のみブロックチェーンに反映される。

2.2 A Network of Channels

マイクロペイメントチャネルは二者間のみの関係を作る。もし、Bitcoin ブロックチェーンにチャネルの大規模ネットワークを仮定し、全てのユーザが少なくとも1つのチャネルをオープンしてこのグラフに参加すると、このネットワークに無数に近いトランザクション量を作ることが可能になる。Bitcoin ブロックチェーンで時期尚早にブロードキャストされる唯一のトランザクションは、非協力的なチャネルの相手とのものである。ハッシュロックとタイムロックでその Bitcoin トランザクションアウトプットを妨げることによって、チャネルのカウンターパーティは資金を完全に盗むことができなくなり、Bitcoin は完全なカウンターパーティの盗難なしで交換できる。

3. Bidirectional Payment Channels

Lightning Network の双方向マイクロペイメントチャネルは、中間ノードのデフォルトのリスクを軽減しながら無制限に近いスケーラビリティを可能にするソフトフォーク展性を必要とする。複数のマイクロペイメントチャネルを一緒に繋げることで、トランザクション経路のネットワークを形成することができる。経路は BGP のようなシステムでルーティングでき、送信者は受信者への特定の経路を指定する可能性がある。出力スクリプトは受信者によって生成されるハッシュによって妨げられている。そのハッシュへの入力を開示することにより、受信者のカウンターパーティは経路に沿って資金を引き出すことができる。

3.1 The Problem of Blame in Channel Creation

このペイメントネットワークに参加するために、あるノードは他のノードとこのネットワーク上にマイクロペイメントチャネルを作成しなければならない。

3.1.1 Creating an Unsigned Funding Transaction

最初のチャネルの Funding Transaction（以下：資産トランザクション）が作成され、どちらかあるいは双方のチャネルカウンターパーティはこのトランザクションの入力に資産を投じることができる。両者が入力と出力を作成するが、署名は行わない。この資産トランザクションの出力は（チャネルの両者による）単一の 2-of-2 マルチシグネチャスクリプトである。両者はこのマルチシグネチャの出力から支出を作成してそれぞれの出資者に元の量を払い戻すまで署名を交換しない。トランザクションに署名しないという目的により、まだ存在していないトランザクションから支出することができる。もし、アリスとボブが資産トランザクションから支出をブロードキャストすることができずに資産トランザクションから署名を交換した場合、もしアリスとボブが協力しなければ永久にその資産がロックされる可能性がある。

アリスとボブはどちらも入力を交換して資産トランザクションに資金を投資し、後で署名するために使用する1つのキーを交換する。このキーは資産トランザクションの 2-of-2 アウトプットに使われる。両者の署名は資産トランザクションからの支出するために必要であり、言い換えれば資産トランザクションの使用には両者の合意が必要ということである。

3.1.2 Spending from an Unsigned Transaction

Lightning Network は署名がまだ交換されていないトランザクションから費やす必要があるため 2-of-2 の資産トランザクション出力から支出するために SIGHASH_NOINPUT トランザクションを使用している。SIGHASH_NOINPUT は、新しい sighash フラグなしでトランザクション ID を取得するために署名される必要があるので、全てのパーティから署名される前に使用することができるトランザクションを保証する。SIGHASH_NOINPUT なしで、Bitcoin トランザクションはそれらがブロードキャストされる前に支出することができない（相手に先に支払いをしないと契約書を作成できなかったかのようなもの）。

SIGHASH_NOINPUT ない場合、資産トランザクションを使用するには子の入力に署名の一部としてトランザクション ID を必要とするため、署名の交換なしではトランザクションから支出を生成することができない。トランザクション ID の要素は親（資産トランザクション）の署名であり、両パーティは子が使用される前に親トランザクションの署名を交換する必要がある。どちらかもしくは両者はそれをしようするために親の署名を知る必要があるので、子が存在する前でも親（資産トランザクション）をブロードキャストすることができる。SIGHASH_NOINPUT は、子が入力に署名なしで使用することを許可するすることで、これを回避する。 SIGHASH NOINPUT は、操作の順序は次のとおりである。

  1. 親（資産トランザクション）の作成
  2. 子（コミットメントトランザクションとコミットメントトランザクションからの全支出）の作成
  3. 子に署名
  4. 子の署名を交換
  5. 親に署名
  6. 親の署名を交換
  7. 親をブロックチェーンにブロードキャスト

参加者はステップ 6 が完了するまで親をブロードキャストすることができない。両者はステップ 6 まで資産トランザクションからの支出するための署名を得ることはできない。さらに、どちらかがステップ 6 中に失敗すると、親は親トランザクションになるために費やされるか、親トランザクションへの入力が二重に費やされる可能性がある（そのため、このトランザクションパス全体が無効になる）。

3.1.3 Commitment Transactions: Unenforcible Construction

署名されていない資産トランザクションを作成した後、両者は最初のコミットメントトランザクションに署名し交換する。コミットメントトランザクションは親（資産トランザクション）の 2-of-2 出力から支出する。ただし、資産トランザクションのみブロードキャストする。資産トランザクションはすでにブロックチェーンに入っており、出力は 2-of-2 のマルチシグネチャトランザクションであり、両者の支出に同意する必要があるため、現在の残高を表すためにコミットメントトランザクションが使用される。 2-of-2 の署名されたコミットメントトランザクションが1つだけ両当事者間で交換される場合、両当事者は、資産トランザクションがブロックチェーンに入った後に確実に返金を受けることができる。 両方の当事者は、チャネルの現在の残高を決済するまで、コミットメントトランザクションをブロックチェーンにブロードキャストしない。彼らは現在のコミットメントトランザクションをブロードキャストすることによってそうする。

コミットメントトランザクションは各パーティに現在の残高をそれぞれ支払う。素朴な実装はブロードキャストされていないトランザクションを構築し、単一のトランザクションから 2-of-2 の支出があり、2つの出力がすべての現在の残高を両方のチャネルの取引相手に返す。これは最初のコミットメントトランザクションを作った時に全ての資産をそれぞれのパーティに返す。

例：アリスとボブがそれぞれ 0.5 BTC を使って単一の出力 1.0 BTC を持つ資産トランザクションの作成に合意し、それぞれに 0.5 BTC ずつを支出するコミットメントトランザクションを作成したとする。コミットメントトランザクションは最初に署名され、キーを交換しどちらも資産トランザクションが不慮にブロックチェーンに入ってしまった時にいつでもコミットメントトランザクションをブロードキャストできるようにする。ここでのポイントは、資産トランザクション署名は安全に交換でき、どちらもコミットメントトランザクションをブロードキャストすることでかれらの資産を救済できることである。

しかし、現在の残高を更新しようとすると、この構造は崩れる。残高を更新するためには、コミットメントトランザクションの出力値を更新しなければならない（資産トランザクションはブロックチェーンに入力されており、変更することはできない）。両者が新しいコミットメントトランザクションに合意し、署名を交換すると、どちらかのコミットメントトランザクションをブロードキャストすることができる。資産トランザクションの出力は一度しか換金することができないため、これらのうち1つだけが有効となる。

例：アリスとボブがチャネルの残高を、0.4 をアリス、0.6 をボブにすることに合意し、それを反映するコミットメントトランザクションを作成すると、どちらかのコミットメントトランザクションをブロードキャストすることができる。実質的には、両当事者がいずれかの残高をブロードキャストするために署名し、署名を交換しているため、どのコミットメントトランザクションをブロードキャストするかを制限することはできない。どちらかがいつでもコミットメントトランザクションをブロードキャストする可能性があるので、結果は新しいコミットメントトランザクションが作成された後、より少ない資産を受け取った一方は、より大きな資産が出力に書かれているコミットメントトランザクションをブロードキャストする著しいインセンティブがある。その場合は結果として、チャネルは即座にクローズされ資産を失う。したがって、このモデルではペイメントチャネルを作ることはできない。

3.1.4 Commitment Transactions: Ascribing Blame

古いコミットメントトランザクションがブロードキャストされることを防ぐ必要がある。ブロックチェーンによって強いられるアクティブな失効の代わりに、Fidelity Bond と同様の方法で自身でチャネルを構築する必要がある。よって、両者がコミットメントやペナルティによって強いられるこれらのコミットメントの違反を作る。もし、一方が合意に違反すると違反者はチャネル内の資産を全て失う。このペイメントチャネルでは契約条件は、両者は最も最近のトランザクションのみをブロードキャスティングすることにコミットすることである。その他の古いトランザクションは契約違反を引き起こし、全ての資産はペナルティとして他のパーティに与えられる。

これを実施するには、誰が古いトランザクションをブロードキャストしたのかを一意に識別できなければならない。これは、各当事者が一意に識別可能なコミットメントトランザクションを持っていれば可能である。両当事者は、他方の当事者がブロードキャストの責任を負うコミットメントトランザクションへの入力に署名しなければならない。一方は、他方の当事者が署名したバージョンのコミットメントトランザクションを持っているため、自分のバージョンのコミットメントトランザクションのみをブロードキャストすることができる。

Lightning Network の場合、資産トランザクションの全ての支出（コミットメントトランザクション）は2つの半分に署名されたトランザクションを持っている。1つはアリスが署名してボブに与えたもの（C1b）、もう1つはボブが署名してアリスに与えたもの（C1a）である。これらの2つのコミットメントトランザクションは同じ資産トランザクションから支出しており、異なるコンテンツを持っている。どちらかは、受け取ったコミットメントトランザクションをブロードキャストすることができるが、その際には、自分のバージョンに相手の署名を含めて署名することで、ブロードキャストすることができる。例えば、ボブは既にアリスから C1b の署名を受け取っているため、トランザクション C1b をブロードキャストすることができる（アリスの署名を含め、ボブ自身が C1b に署名する）。このトランザクションは、アリスとボブの署名を必要とする資産トランスアクションの 2-of-2 出力からの有効な支出となります。

しかし、この構造でさえ、一方は単に責任を割り当てられているだけである。Bitcoin ブロックチェーンでこの制約を強いることはまだ不可能である。ボブはアリスが古いトランザクションをブロードキャストしないことをまだ信頼している。この時、彼はアリスがやったことを半分の署名された取引証明で証明することしかできない。

3.2 Creating a Channel with Contract Revocation

実際に制約条件を強いるためには、一方が無効にできるコミットメントトランザクションを構築する必要がある。この失効は、検証パスを決定するためにトランザクションがブロックチェーンに入るタイミングに関するデータとトランザクションの成熟度を使用して達成可能である。

3.3 Sequence Number Maturity

Mark Freidenbach は、シーケンス番号はソフトフォークを介した親トランザクションの相対的なブロック成熟度を介して強制可能であることを提案している。これにより、支出スクリプトの相対的なブロック確認時間のロックを何らかの形で確保する基本的な機能が可能になる。加えて、追加のオペコード、OP _CHECKSEQUENCEVERIFY（別名：OP_RELATIVECHECKLOCKTIMEVERIFY）はトランザクション展性を解決するためのより恒久的な解決策の前に、その場しのぎの解決策を可能にするなど、さらなる能力を可能にするだろう。

無効可能トランザクションは、トランザクションが出力スクリプトのユニークなタイプを持つユニークな出力から支出する。この親の出力には2つの償還パスがあり、1つ目はすぐに償還され、2つ目は子がトランザクション間の最低確認数を持っている場合にのみ償還される。これは、子トランザクションのシーケンス番号を、親からの確認の最小数を要求するようにすることで達成される。要するに、この新しいシーケンス番号の動作は、出力と償還トランザクションの間のブロック数が指定されたブロックの高さを超えている場合にのみ、この出力からの支出を有効にすることを可能にする。

3.3.1 Timestop

悪意のある攻撃者によるトランザクションフラッディングを軽減するには攻撃が失敗するという確実な脅しが必要である。これは、マイナーが現在のメモプールがトランザクションで溢れているかどうかを特定することを可能にすることによって軽減できる。彼らは、ブロックヘッダーのバージョンナンバーの最終ビットに "1" を挿入することができる。もしブロックヘッダーの最終ビットに "1" が入っていたら、そのブロックは nSequence 値の相対的な高さの成熟度にカウントされず、そのブロックは混雑したブロックとして指定される。混雑していないブロック高は nSequence に使われ、ブロック成熟度にカウントされる。

例：親トランザクション出力が nSequence 値が 10 で子によって支出される場合、そのトランザクションが有効になるまで 10 個の承認を待つ必要がある。しかし、もし timestop フラグがセットされていると、新しいブロックでも承認カウントはストップする。フラグが立っているとき、nSequence 値を使用している全てのトランザクションはフラグがなくなるまでカウントを停止する。これにより、現在の補助的な timestop ブロックの高さのトランザクションがブロックチェーンに入るのに十分な時間とブロックスペースが与えられ、システム攻撃者がシステムを攻撃することに成功するのを防ぐことができる。

しかし、これは timestop ブロックであるかどうかを指定するために、ブロック内に何らかのフラグが必要である。SPV の完全な互換性のためには、これはコインベースではなく 80 バイトのブロックヘッダ内にあることが望ましい。ブロックヘッダーないにこのフラグを置くのに適している可能性のある場所が2つある。ブロックタイムとブロックバージョンである。ブロックタイムは ASIC マイナーによるエントロピーソースとして最終ビットが使用されるため、安全でない可能性がある。従って、timestop ビットのためにビットを消費される必要があるかも知れない。もう一つの選択肢として、timestop の起動をハードコンセンサスルールとしてハードコード化することもできます(例えば、ブロックサイズを介して)。timestop ルールにまともなデフォルトをセットすることで、これらのルールはコンセンサスソフトフォークなしで変更できる。もし、ブロックバージョンがフラグとして使用されると、コンテキスト情報は一部のマージマイニングされたコインで使用されている Chain ID と一致しなければならない。

3.3.2 Revocable Commitment Transactions

責任の分担と取消可能トランザクションを組み合わせることで、当事者が契約の条項を守っていない場合に判断し、相手を信用することなく罰則を行使することができる。

新しいコミットメントトランザクションを作成する意図は、それで新しい残高を更新するときに全ての古いトランザクションを無効にすることである。古いトランザクションの無効は、出力を取り消し可能シーケンス成熟契約（RSMC：Revocable Sequence Maturity Contract）にすることで発生することができる。あるトランザクションを無効にするためには、古い取引が誤ってブロードキャストされた場合にすべての資産を相手に与えることを双方の当事者によって署名され、交換される。誤ったブロードキャストは、同じ最終出力の異なる2つのコミットメントトランザクションを作ることによって特定されるが、自分自身への支払いは RSMC によって負担されている。

実質的には、単一の資産トランザクション 2-of-2 出力から2つのコミットメントトランザクションがある。この2つのうち1つのみがブロックチェーンに挿入することができる。チャネル内の各パーティはこの契約の1つのバージョンを持っている。つまり、これが最初のコミットメントトランザクションペアであれば、アリスとボブのコミットメントトランザクションは C1a と C1b で定義される。どちらかがコミットメントトランザクションをブロードキャストすることでチャネルをクローズして終了するように要求する。最初のコミットメントトランザクションの2つの出力には、チャネルカウンターパーティでの未割り当て残高のデリバリートランザクション（ペイアウト）を含んでいる。もし、アリスが C1a をブロードキャストするとボブに資産を送る D1a によって出力の1つが支出可能になる。デリバリートランザクション（D1a / D1b）は即座に換金可能であり、コミットメントトランザクションがブロードキャストされたとしても妨げられない。

各パーティのコミットメントトランザクションについて、彼らが所有する最も最近のコミットメントトランザクションをブロードキャストしていることを証明する。これが現在の残高であることを証明しているのだから、ペナルティとして相手に資産を支払っても直接的な利益は得られないので、相手に支払った残高は事実であると仮定している。

しかし、コミットメントトランザクションをブロードキャストした人へ支払った残高は未検証である。そのコミットメントトランザクションが最も最近のものかどうかをブロックチェーン参加者は知らない。もし、彼らが最新のバージョンをブロードキャストしない場合、チャネルで全ての資産を相手に与えることで罰せられる。彼ら自身の資産は彼らの RSMC で負担されるため、コミットメントトランザクションがブロックに含まれてから決められた数の承認の後に彼らの資産を主張することができる。もし、彼らが最新のコミットメントトランザクションをブロードキャストすると、その取り消し可能トランザクションに変わる取り消し可能トランザクションは存在しないはずであるため、一定の時間が経過すると資産を受け取ることができる。コミットメントトランザクションを誰がブロードキャストしたのかを知り、自分の支払いを予め定められた期間ロックすることで、将来的にコミットメントトランザクションを取り消すことができるようになる。

3.3.3 Redeeming Funds from the Channel: Cooperative Counterparties

どちらかのパーティはチャネルから資産を換金する可能性がある。しかし、コミットメントトランザクションをブロードキャストしたそのパーティはあらかじめ決めた承認を待つ必要がある。ブロードキャストしていない当事者はすぐにその資産を換金する可能性がある。

例：1 BTC がコミットされた資産トランザクションがあり、ボブが最新のコミットメントトランザクション（C1b）をブロードキャストすると、アリスが 0.5 BTC 支出できる一方でボブは 0.5 BTC 得るまで 1000 承認を待つ必要がある。アリスの場合、ボブが正しいコミットメントトランザクションをブロードキャストしたことを認めると、このトランザクションは完全にクローズされる。コミットメントトランザクションがブロックチェーンに入って 1000 ブロックが経過したあと、ボブは取り消し可能デリバリートランザクションをブロードキャストすることができる。ボブは C1b が取り消されていないことを証明するために 1000 ブロック待つ必要がある。1000 ブロック後、取り消し可能デリバリートランザクションはブロックに含めることができるようになる。もし、当事者が 1000 ブロックよりも前にブロックに入れようとした場合、そのトランザクションは 1000 回の承認が行われた後まで無効となる（その時点で出力がまだ償還されていない場合は有効となる）。

ボブが取り消し可能デリバリートランザクションをブロードキャストした後、チャネルはアリスとボブによって完全にクローズされ、両者は合意した資産を受け取る。もし、それがアリスの代わりにコミットメントトランザクション（C1a）をブロードキャストしたのであれば、ボブの代わりに 1000 回の承認を待たなければならないのはアリスの方である。

3.3.4 Creating a new Commitment Transaction and Revoking Prior Commitments

各当事者が最新のコミットメントトランザクションをブロードキャストしてクローズする一方で、新しいコミットメントトランザクションを作ることを選択して古いものを無効にする可能性もある。

アリスとボブは 0.5 BTC ずつ持っている現在の残高を、アリスが 0.4 BTC、ボブが 0.6 BTC に払い戻すように更新したいとする。これに両者が合意をすると新しいコミットメントトランザクションのペア（C2a / C2b）を作成する。

新しいコミットメントトランザクションに署名し交換すると、古いものが無効となる。この無効化は、両当事者に違反対策トランザクション（BR1）に署名させることで発生し、これは取消可能デリバリートランザクション（RD1）に取って代わる。各当事者は、コミットメントトランザクションからの支出である自分の RD1 からの半署名入りの BR1 を相手に手渡す。違反対策トランザクションは、チャネルの現在の残高の範囲内ですべてのコインを取引相手に送る。

例：アリスとボブは新しいコミットメントトランザクション（C2a / C2b）を作成して前のトランザクション（C1a / C1b）を無効にし、後にボブが誤った C1b をブロードキャストした場合、アリスはチャネル内のボブの全ての資産を手に入れることができる。なぜなら、ボブは C1b を決してブロードキャストしないことをペナルティを通してアリスに証明しているため、C1b がブロードキャストされた瞬間にアリスはボブの資産を回収することができる。実質的に、当事者で違反対策トランザクションを構築することによって、過去のコミットメントをブロードキャストしないことを証明している。この合意に違反した時にチャネル内の全ての資産を失うため、当事者はこれを受け入れることができる。

このため、違反対策取引が相手方に渡された時点で、それまでのコミットメントトランザクションを全て削除することになる。もしどちらかが誤ったものをブロードキャストすると、全ての資産が相手に行ってしまう。

例：ボブが C1b をブロードキャストすると、あらかじめ定義されたブロック数（この場合は 1000 ブロック）内でアリスがブロックチェーンを見ている限り、アリスは RD1b をブロードキャストすることで、このチャネルのすべてのお金を取ることができるようになる。C2a と C2b の状態が 0.4 BTC がアリス、0.6 BTC がボブだとしてもボブが違反したため全ての資産がアリスに移る。機能的には、取り消し可能トランザクションはボブがチャネルの規則に違反したことを証明し、これはブロックチェーンによってプログラム的に裁かれる。

しかし、もしアリスが 1000 ブロック以内に BR1b をブロードキャストしない場合、RD1b は 1000 ブロック以降に有効になるため、ボブはいくらかのお金を盗むことができる可能性がある。不正なコミットメントトランザクションがブロードキャストされた場合、違反対策トランザクションのみが 1000 ブロック以内でブロードキャストすることができる。1000 ブロック後は BR1b も RD1b もいつでもブロードキャストすることができる。違反対策トランザクションは、この事前に定義された期間内にのみ排他性を持っており、それ以降の任意の時間は、機能的に時効の満了である。

このため、取引相手が無効なコミットメントトランザクションをブロードキャストしていないかどうか、定期的にブロックチェーンを監視したり、第三者に委任したりする必要がある。第三者は、この第三者に違反対策トランザクションを与えることで委任することができる。これらの第三者に出力に何らかの手数料を与えることで、カウンターパーティの悪意があった場合にブロックチェーンがそのようなトランザクションをブロードキャストするのを見るようにインセンティブを与えることができる。第三者が行動を起こせるのは相手が悪意を持って行動しているときだけなので、この第三者はチャンネルを強制的に閉じる力を持っていない。

3.3.5 Process for Creating Revocable Commitment Transactions

取り消し可能コミットメントトランザクションを作るには初めから適切なチャネルを構築し、将来いつでもブロードキャストされる可能性があるトランザクションにのみ署名し、非協力的な相手や悪意のある相手によって損をすることがないようにする必要がある。これは、SIGHASH_NOINPUT を使用する場合、各コミットメントトランザクション RSMC（および HTLC）の出力に固有の鍵を使用する必要があるため、新しいコミットメントに使用する公開鍵を決定する必要がある。公開鍵を指定するために $P$ を使用し、署名に使用する秘密鍵を指定するために $K$ を使用する。最初のコミットメントトランザクションを作成する時、アリスとボブは単一の $multisig(P_{AliceF}, P_{BobF})$ 出力で資産トランザクション（それぞれ 0.5 BTC の資金で合計 1 BTC の資金を調達したもの）からマルチシグ出力を作ることに合意する。この出力は資産トランザクションから支出するためには両者の合意が必要である Pay to Script Hash トランザクションである。彼らはまだ使用可能な資産トランザクション（$F$）を作成していない。また、$P_{AliceF}$ と $P_{BobF}$ は資産トランザクションのみに使用され、他では使用されない。

デリバリートランザクションは当事者らが前もって指定している P2PKH 出力もしくは P2SH トランザクションであるため、$P_{AliceF}$ と $P_{BobF}$ の出力として生成される。単純に、資産はコミットメントトランザクションがブロックチェーンに挿入されたあとにその指定された受取人によって完全に制御されるので、これらの出力アドレスはチャネルの全体で同じままである。両当事者はコミットメントトランザクションに使用する RSMC に使用するための公開鍵を交換する。コミットメントトランザクションの各集合は彼ら自身の公開鍵を使用し、決して再利用されない。コミットメントトランザクションからの出力値を知ったのちに、コミットメントトランザクションのペアを作成する（署名は交換しない）。彼らは取り消し可能デリバリートランザクション（RD2a / RD2b）に署名し、署名を交換する。例えば、ボブは RD1a に署名し、$K_{BobRSMC2}$ を使ってアリスに送信する。両者が取り消し可能トランザクションを受け取った時、コミットメントトランザクションを交換する。例えば、ボブは $K_{BobF}$ を使用して C1a に署名し、アリスに送る。

この時、前のコミットメントトランザクションは新しいコミットメントトランザクションと同様にブロードキャストすることができる。C1a / C1b と C1a / C2b はどちらも正当である。C1a / C1b を無効にするために、違反対策トランザクション（BR1a / BR1b）署名交換する。例えば、アリスは $K_{AliceRSMC1}$ を使用してボブに BR1a を送る。BR1a / Br1b 両方が交換されたとき、チャネルの状態は現在のコミットメント C2a / C2b になっており、残高はコミットされている。

しかし、BR1a / BR1b 署名を公開するのではなく、秘密鍵を相手に公開するだけでも可能である。自身のコミットメントトランザクションで使われている秘密鍵を後悔することができる。例えば、ボブが C1b を無効にしたい場合、C1b に使われている秘密鍵をアリスに送る（彼は C1a で使用した鍵を公開していない。それはコインの窃盗を許すことになるからだ）。ボブが間違って C1b をブロードキャストしてしまった場合、アリスは C1b の出力に使われている秘密鍵をすべて持っているので、お金を取ることができる。しかし、C1b をブロードキャストできるのはボブだけだ。このコイン盗難のリスクを防ぐために、ボブは古いコミットメントトランザクションをすべて破棄する必要がある。

3.4 Cooperatively Closing Out a Channel

両者は、意見の相違があった場合には、いつでもブロックチェーンに現在の状態を伝えることができることを知っているため、彼らのチャネルに利用可能な資産がある限り、当事者に好きなだけ支払いをすることができる。ほとんどの場合、資産トランザクションの全ての出力はブロックチェーンに決してブロードキャストされないだろう。相手が非協力的な場合に備えて存在しているだけで、契約が法廷で執行されることはほとんどないのと同じである。契約が確定的に執行される能力が証明されていることは、両当事者が誠実に行動するための十分なインセンティブとなる。

どちらかがチャネルを協力的にクローズしたい場合、相手とコンタクトを取り、スクリプトによる制限なしで現在のコミットメントトランザクションの出力で資産トランザクションから支出することで可能である。それ以上チャネルに支払いは発生しない。

協力的にチャネルをクローズする目的はブロックチェーンに現れるトランザクションの数を減らし、両者が資産を即座に受け取ることができるようにするためである。チャネルは、協力して取引を終了することを決定するまで永続的に存続することができ、一方の当事者が他方の当事者に協力せず、チャネルがブロックチェーン上でクローズアウトされて強制される場合もある。

3.5 Bidirectional Channel Implications and Summary

チャネルが双方の同意を得た上でのみ更新できるようにすることで、ブロックチェーンの中に永続的に存在するチャネルを構築することが可能になる。両者はチャネル内の残高を彼らが望むように更新することができる。どちらかが違反をした場合、どちらかがチャネルをクローズし現在の状態をブロックチェーンにブロードキャストする可能性がある。取り消し可能トランザクションを使用することで、もしどちらかがチャネルの規範に違反すると資産が他者に譲渡され、提供された違反対策トランザクションがブロックチェーンに挿入される。もし、両者が協力的な場合、チャネルは無制限にオープンすることができる。

この種の構築は、Bitcoin のコンセンサスの一部としてブロックチェーン上でプログラム的に裁定が行われるため、相手を信頼する必要がないからこそ可能である。結果として、あるチャネル当事者は完全な管理や資産の制御を所有していない。

4. Hashed Timelock Contract (HTLC)

双方向ペイメントチャネルはチャネル内における資産のセキュアな移転を可能にする。複数のチャネルをまたいだ移転を可能にすることは Hashed Timelock Contract（HTLC）という追加の契約が必要である。HTLC の目的は、グローバルステートをハッシュを通して複数ノードを横切ることである。グローバルステートは、プリイメージの開示を通じた時間的なコミットメントと時間ベースの資源解放によって確保されている。取引的「ロッキング」はコミットメントを通じてグローバルに発生し、任意の時に一人の参加者は次の参加者へプリイメージ $R$ についての知識を持っているかどうか開示する責任がある。この契約はあるチャネル当事者の管理者や他の参加者のトラストが必要ない。

これを達成するために、HTLC はあるチャネル当事者に情報を開示すると同時に、nLockTime を使用して特定の日程をすぎると有効になるトランザクションを作ることができなければならない。さらに、このデータは HTLC を元に戻すことができなければならないので、取り消すことができなければならない。HTLC はブロックチェーンを通して強制できる、ある当事者のチャネル契約でもある。チャネル当事者は HTLC での以下の項目に合意する。

  1. もし3日内でボブが、ハッシュ値 $H$ から知らない 20 バイトのランダムな入力データ $R$ をアリスに作ることができたら、アリスはボブに 0.1 BTC 支払うことでその契約を済ませる。
  2. もし3日が経過したら、上記の条項は意味がなくなり、清算手続は無効となるため、当事者双方は3日を経過した後は、和解して支払いを請求しようとしてはいけない。
  3. いずれかの当事者は、本契約の参加者双方が同意する限り本契約の条件に従って参加者が選択した任意の方法で支払いを行い、本契約を早期に終了させることができる。
  4. 上記の条件に違反した場合、本契約にロックされている資金の最大のペナルティが課せられ、相手に支払われる。

例をわかりやすくするために、HTLC には日数を、RSMC にはブロックの高さを使用する。実際には、HTLC もブロックの高さ（例えば、3 日は 432 ブロックに相当）として定義する必要がある。実際には、ある時間枠内に受信者が $R$ を知っていることを条件とした支払いを構築したいと考えている。この時間枠の後、資金は送信者に戻って返金される。RSMC と同様に、これらの契約条件は Bitcoin ブロックチェーン上でプログラム的に強制され、違反はすべて一方的に身元保証（コミットメントステートからのペナルティ取引の支出を使用して構築される）を介してペナルティが課されるため、契約条件を遵守するための取引相手への信頼を必要としない。もしボブが期日までに $R$ を知ったら、彼はトランザクションをブロードキャストすることで資産を払い戻すことができる。スクリプトはトランザクションが Bitcoin ブロックチェーン上で使用されたとき正当となるので、アリスはその資産を保留することはできない。

HTLC はコミットメントトランザクションの追加の出力であり、ユニークなスクリプトを持つ。

OP_IF
      OP_HASH160 <Hash160 (R)> OP_EQUALVERIFY 2 <Alice2> <Bob2> OP_CHECKMULTISIG
OP_ELSE
     2 <Alice1> <Bob1> OP_CHECKMULTISIG
OP_ENDIF

概念的には、このスクリプトは単一の HTLC 出力から2つのパスがある。1つ目（OP_IF）は、ボブが $R$ を作ることができた場合である。2つ目は、3日間のタイムロックによって償還され、アリスに払い戻すパスである。その3日間タイムロックは支出トランザクションから nLockTime を用いて強制される。

4.1 Non-revocable HTLC Construction

もし、$R$ が3日以内に作られたら、ボブはデリバリートランザクションをブロードキャストすることでその資産を払い戻すことができる。$R$ が含まれていないデリバリートランザクションは無効であるが、3日経てばタイムアウトトランザクションをブロードキャストすることでその資産はアリスの元へ払い戻される。3日経過して、$R$ が公開されるとどちらかのトランザクションが正当となる。残高が正しいかどうかを確認するために、トランザクションをブロックチェーンに入れることができるようにするのは、両当事者の個人的な責任の範囲内である。ボブの場合、資産を受け取るために Bitcoin ブロックチェーンにデリバリートランザクションをブロードキャストするか、アリスと決済しなければならない（HTLC をキャンセルしながら）。アリスの場合、払い戻しを受け取るために今から3日以内にタイムアウトトランザクションをブロードキャストするか、ボブと一緒に完全に HTLC をキャンセルしなければならない。

単純化しすぎたこの種の構造は誤った双方向チャネル構造として同様の問題をまだ持っている。古いコミットメントトランザクションがブロードキャストされると、両方のパスはその後に有効である可能性があるためどちらかの当事者が資金を盗もうとする可能性があります。例えば、もし $R$ が1年後に公開され、無効なコミットメントトランザクションがブロードキャストされると、両方のパスが有効になりどちらかによって払い戻し可能になる（ブロックチェーン上ではまだ契約が成立していない）。アリスは自分の払い戻しをもらうため、HTLC をクローズすることは絶対的に必要であり、契約を中断し払い戻しを受け取らなければならない。一方でボブが3日経ってから $R$ を発見した時、彼はアリスに送るはずだった資産を盗むことができる可能性がある。非協力的なパーティは新しいコミットメントトランザクションを作る気がないのでブロックチェーンにそれをブロードキャストせずに HTLC を中止することは不可能である。

4.2 Off-chain Revocable HTLC

Bitcoin ブロックチェーンにブロードキャストせずにオフチェーンで契約を停止するためには、出力に RSMC を組み込む必要がある。

アリスとボブは 0.5 ずつの残高を示すコミットメント１から残高を更新したいと仮定する。アリスは3日以内に $R$ を知ることを条件にボブに 0.1 送りたいを考えている。もしボブが $R$ を作ることができず3日が過ぎると、アリスは自分のお金を戻したい。

新しいコミットメントトランザクションはアリスとボブへの現在の残高の払い戻し（Output0,1）が含まれている。Output2 は HTLC で、輸送中の資金を記述します。アリスの 0.1 が HTLC で負担されるので残高が 0.4 に減っており、ボブは 0.5 のままである。この新しいコミットメントトランザクション（C2a / C2b）は支出可能な2つの HTLC 出力を持っている。双方向ペイメントチャネルと同様に、一方がコミットメントをブロードキャストしたとき、相手への支払いは正当と見なされるだろう。

HTLC トランザクションはコミットメントトランザクションの間で存続する可能性がある。各 HTLC は、トランザクション（C2a と C2b）の各サイドにつき 4 つの鍵を持ち、カウンターパーティにつき合計 8 つの鍵を持つ。コミットメントトランザクションの HTLC 出力には取引相手ごとに2つの鍵が用意されている。アリスのコミットメントトランザクション（C2a）の場合、HTLC 出力スクリプトは、$R$ の開示によって負担された $multisig(P_{Alice2},P_{Bob2})$ と、負担されていない $multisig(P_{Alice1},P_{Bob1})$ を必要とする。ボブのコミットメントトランザクション（C2b）の場合、HTLC 出力スクリプトは、$R$ の開示によって負担された $multisig(P_{Alice6},P_{Bob6})$ と、負担されていない $multisig(P_{Alice5},P_{Bob5})$ を必要とする。HTLC の出力状態は、どのコミットメントトランザクションがブロードキャストされるかによって異なる。

4.2.1 HTLC when the Sender Broadcasts the Commitment Transaction

送信者アリスの場合、デリバリートランザクションは RSMC で負担されていない HTLC 実行デリバリートランザクション（HED1a）として送信される。アリスはブロードキャストしたコミットメントトランザクションは最も最近のものであると証明しているので、この HTLC はオフチェーンで決して停止されないと仮定する。もしボブがプリイメージ $R$ を作ることができた場合、彼はブロックチェーンにコミットメントトランザクションがブロードキャストされた後で HTLC から資産を払い戻すことができる。

アリスが C2a をブロードキャストした場合、このトランザクションは $multisig(P_{Alice2},P_{Bob2})$ を消費する。アリスだけが HED1a のためにボブに署名をしたので、ボブだけが HED1a をブロードキャストすることができる。しかし、HTLC が形成されてから3日が経過すると、アリスはタイムアウトトランザクション（HT1a：HTLC Timeout transaction）をブロードキャストするだろう。これは RSMC である。アリスが C2a をブロードキャストする場合、$R$ の公開の必要とせずに出力 $multisig(P_{Alice1},P_{Bob1})$ を消費する。このトランザクションは3日が経過するまでブロックチェーンに挿入することはできない。このトランザクションの出力は、1000 ブロックの相対成熟度を持つ $multisig(P_{Alice3},P_{Bob3})$ と、確認成熟度の要件を持たない $multisig(P_{Alice4},P_{Bob4})$ を持つ $RSMC$ である。ボブだけが HT1a の署名をアリスに与えているので、アリスのみがそれをブロードキャストできる。

HT1a がブロックチェーンに挿入され、1000 ブロックの承認が発生すると、HTLC タイムアウト取り消し可能デリバリートランザクション（HTRD1a）が $multisig(P_{Alice3},P_{Bob3})$ を消費してアリスによってブロードキャストされる可能性がある。これはブロックの成熟要件に満たない $multisig(P_{Alice4},P_{Bob4})$ を使用して他のトランザクションが HTRD1a に取って代わるときに取り消すことができる。

4.2.2 HTLC when the Receiver Broadcasts the Commitment Transaction

受信者ボブの場合、受信者のタイムアウトトランザクションは HTLC タイムアウトデリバリートランザクションとして払い戻される。このトランザクションはその資産を元の送信者（アリス）へ直接払い戻し、RSMC で負担されていない。ボブはブロードキャストした C2b は最も最近のものだと証明しているので、この HTLC はオフチェーンで決して停止しないと仮定する。もし3日が経過すると、アリスは HTD1b をブロードキャストして還付を受け取ることができる。ボブが C2b をブロードキャストすれば、このトランザクションは $multisig(P_{Alice5},P_{Bob5})$ を消費する。しかし、もし、HTD1b が3日以内にブロードキャストされずボブがプリイメージ $R$ を知っていたら、彼は HTLC 実行トランザクション（HE1b）をブロードキャストすることができる（彼が $R$ を作ることができれば）。このトランザクションは RSMC である。ボブが C2b をブロードキャストした場合、それは出力 $multisig(P_{Alice6},P_{Bo6})$ が消費され、$R$ の公開が必要である。このとらトランザクションの出力は 1000 ブロックの相対成熟度を持つ $multisig(P_{Alice7},P_{Bob7})$ と、確認成熟度の要件を持たない $multisig(P_{Alice8},P_{Bob8})$ を持つ $RSMC$ である。アリスのみが HE1b の署名をボブに送っているので、ボブのみがそれをブロードキャストすることができる。

HE1b がブロックチェーンに挿入され 1000 ブロックの承認が発生すると、$multisig(P_{Alice7},P_{Bob7})$ を消費した HTLC 実行取り消し可能トランザクション（HERD1b）をボブがブロードキャストする可能性がある。

4.3 HTLC Off-chain Termination

HTLC が構築された後、オフチェーンで HTLC を停止するには両者がチャネルの状態を合意する必要がある。もし受信者が相手に $R$ の情報を証明できたら、受信者は Bitcoin ブロックチェーン上のチャネルを即座にクローズすることができ資産を受け取ることができることを証明している。この時点で、両者がチャネルをオープンのままにしておきたいと思っていたら、オフチェーンで HTLC を停止し、新しい残高を反映させる新しいコミットメントトランザクションを作るべきである。

同様に、もし受信者が $R$ を公開することで $R$ の情報を証明できない場合、両者は HTLC を停止することに合意し、送信者へ払い戻しする HTLC での残高で新しいコミットメントトランザクションを作成するべきである。もし相手と合意できなかった、もしくは無反応になった場合は Bitcoin ブロックチェーン上で必要なチャネルトランザクションをブロードキャストすることによってそのチャネルをクローズするべきである。しかし、彼らが協力的であれば、違反対策トランザクションを交換することで、古いコミットメントを無効にすることができる。加えて、彼らが特定の HTLC を停止している場合、その HTLC トランザクションで使われている秘密鍵も交換しておく必要がある。

例えば、アリスが HTLC を停止したいと思っており、$K_{Alice1}$ と $K_{Alice4}$ をボブに公開する。同様に、ボブも停止したければアリスに$K_{Bob6}$ と $K_{Bob8}$ を公開する。秘密鍵を相手に公開した後にアリスが C2a をブロードキャストすると、ボブは HTLC から即座に全ての資産を受け取ることができる。ボブが C2b をブロードキャストした場合は、アリスが全ての資産を受け取ることができる。

4.4 HTLC Formation and Closing Order

新しい HTLC を作ることは、新しいコミットメントトランザクションの署名の前に HTLC の署名を交換することを除けば、新しいコミットメントトランザクションを作成することと同じプロセスである。ある HTLC をクローズ（C2 から C3）するプロセスは以下の通りである。

  1. アリスは RD3b と C3b の署名を送る。この時点でボブは同じ払い戻しの C3b と C2b のブロードキャストを選択できる。ボブは C3b を受け取った後、C2b を終了することを望む。

  2. ボブは RD3a と C3a に署名し、コミットメント２と HTLC の終了に使用した秘密鍵と同様に署名を送る。この時点では、ボブは C2b をブロードキャストしてはいけない。ボブは C2b とその HTLC を完全に失効させた。アリスは C3a を受け取った後、C2b を終了することを望んでいる。

  3. アリスは RD3b と C3b に署名し、コミットメント２と HTLC を終了するために使用した秘密鍵と同様に、RD3b と C3b に署名して送信する。この時点では、どちらのパーティもコミットメント2をブロードキャストすべきではない。旧コミットメントと旧 HTLC は、これで取り消され、完全に終了した。HTLC を持たない新しいコミットメント3のみが残っている。

    HTLC が閉じられたとき、チャネル内の現在の残高が HTLC 契約が完了してブロックチェーン上でブロードキャストされたときに発生するであろうものとなるように、資金は更新される。その代わりに、両当事者はオフチェーン更新を行い、チャネル内で支払いを更新することを選択する。両者が指定された時間内にオフチェーン更新を完了させることが絶対に必要である。受信者（ボブ）の場合、彼は $R$ を知っていて、3日以内にアリスとの残高を更新しなければならない、そうでなければ、アリスはそれを3日以内に払い戻すだろう。アリスの場合、タイムアウトが有効になってからすぐに、彼女は HTLC タイムアウトトランザクションを更新するかブロードキャストしなければならない。HTLC タイムアウトが有効になった後すぐに、彼女は HTLC タイムアウト取消可能デリバリートランザクションを更新するか、ブロードキャストしなければならない。取引相手が更新する気がないか、あるいは送らせている場合は、HTLC トランザク ションを含む現在のチャネルの状態を Bitcoin ブロックチェーン上にブロードキャストしなければならない。

5. Key Storage

鍵は BIP 0032 階層決定的ウォレットを用いて生成される。例えば、アリスは10億の鍵を事前に生成し、各鍵は前鍵の子である。アリスは、ある決定論的な方法で使用する鍵を割り当てる。例えば、アリスは1日目に多くのサブ鍵を生成するためにツリーの最深層の子から始める。この鍵は1日目に生成される全ての鍵のマスター鍵として使用される。アリスは、次のトランザクションで使用したいアドレスをボブに与え、それが無効になった時にその秘密鍵を公開する。アリスがその日のマスター鍵から生成された全ての秘密鍵をボブに公開して、そのマスター鍵を使用して継続したくない場合、アリスはボブに1日目のマスター鍵を公開することができる。この時点でボブは1日目のマスター鍵から生成された全ての鍵を保存する必要はない。

2日目の秘密鍵がすべて交換されたとき、たとえば5日目までに、アリスは2日目の鍵を公開します。ボブは1日目の鍵が2日目の鍵の子であるため、1日目の鍵を2日目の鍵から生成することができる。取引相手が間違ったコミットメントトランザクションをブロードキャストした場合、資金回収のためのトランザクションでどの秘密鍵を使用するかは、ブルートフォースで決定する。もしくは両当事者が合意した場合には、トランザクションを作成する際にシーケンスID番号を使用して、どの鍵セットを使用するかを識別することができる。これにより、チャネルの参加者は、あまりデータを使用せずに事前の出力状態（トランザクション）を両当事者によって無効にできる。マークルツリーで事前に用意した秘密鍵を公開することで、チャネルごとに数キロバイトのデータだけで何百もの古いトランザクションを無効にすることができる。Lightning Network のコアチャネルは大きなストレージコストを必要とせずに数10億のトランザクションを処理可能である。

6. Blockchain Transaction Fees for Bidirectional Channels

参加者ごとに異なるバージョンのトランザクションを生成して、誰がブロックチェーン上でトランザクションをブロードキャストしたのかを非難することが可能です。誰がトランザクションをブロードキャストしたのかを知り、責任を負わせることができるようになることで、第三者サービスを利用して、2-of-3 マルチシグのエスクローで手数料を保持することができる。もし、誰かがファンディングをクローズすることを合意したり、新しいコミットメントコミットメントトランザクションで置き換える代わりにトランザクションチェーンをブロードキャストしたい場合、第三者機関と通信してブロックチェーンにチェーンをブロードキャストする。もし、当事者が協力するための第三者からの通達を拒否した場合、ペナルティは非協力パーティに課せられる。ほとんどの場合、参加者は非協力的な取引相手のイベントでのトランザクション手数料に無関心な可能性がある。

7. Pay to Contract

支払いの証明として、暗号的に証明可能な「Delivery Versus Payment」契約、Pay-to-contract を構築することが可能である。この証明は特定値の支払いとして hash(R) から入力 $R$ の知識として確立することができる。買い手と売り手の間での契約において、$R$ を知っていることが送金された資金の証明であること条項を組み込むことによって、その資金の受取人は支払いを確実に受け取るだろうという $R$ を公開することにインセンティブがない。その資金が最終的に買い手から引き出されたとき、$R$ は資金の引き出しの一部として公開される。送信者は、その後、支払いが発生する前に、紙の契約の履行として扱われるハッシュのための入力の知識を持つ暗号的に署名された契約を手配することができる。

8. The Bitcoin Lightning Network

ハッシュロックとタイムロックによって束縛された契約を持つマイクロペイメントチャネルを持つことで、追加の中央清算機関を持たずに、一連の減少するタイムロックを使用してマルチホップ決済ネットワーク上でトランザクションを清算することが可能になる。金融市場は中央点で転送の責任を移動することによってトランザクションを清算し、中央のハブを通して所有権を移動することで決済をする。

Bitcoin はプログラム可能通貨を可能にするため、中央清算機関にコンタクトすることなく取引を行うことができる。取引はオフチェーンで実行することができ、第三者が資金を回収してから資金を分配することはない。資金を末端の受取人に配送する義務は委任の連鎖プロセスを通して達成される。そのパスに沿った各当事者は特定の受取人への配送義務があり、次の参加者へと義務を引き継いでいく。それぞれの HTLC で定義されたパス上のその後の参加者の義務は、前の参加者に比べて完了までの時間が短い。このようにして、各参加者はパスに沿って義務が送られてきたときに、確実に資金を請求することができるようになる。

8.1 Decrementing Timelocks

アリスがデイブに 0.001BTC 送りたいと仮定する。アリスはボブとキャロルを通るルートを見つける。送信パスは以下の図のようになる。

アリスがデイブに送信するとき、この支払いのためにデイブに hash(R) を要求する。受取人までのホップ数を数えて、HTLC の有効期限として使用する。このケースでは HTLC 有効期限を3日に設定する。ボブはキャロルと有効期限が2日の HTLC を作成し、キャロルとデイブは1日の HTLC を作成する。デイブは現在、キャロルに $R$ を開示することは自由であり、両当事者は、代替のコミットメントトランザクションで更新を介した即時の決算に合意する可能性が高い。そして、これはアリスに戻ってステップバイステップで行われる。これはオフチェーンで発生し、すべての当事者が協力的な場合はブロックチェーンには何もブロードキャストされない。

減分するタイムロックは、パスに沿っているすべての当事者が、$R$ の開示によって開示する当事者が資金を引き出すことができることを知っているように使用される。もし、デイブが1日以内にキャロルに $R$ を生成しない場合、キャロルはその HTLC をクローズするだろう。1日後にデイブが $R$ をブロードキャストした場合、彼はキャロルから資金を引き出すことはできない。ボブに対するキャロルの責任は2日目に発生するため、キャロルがブロックチェーンへの送信または更新を介してデイブとのトランザクションを更新することを条件に、ボブから資金を引き出す能力がなければ、キャロルがデイブへの支払いの責任を負うことはない。

パスの途中（例えば2日目）で $R$ が参加者に開示された場合、パスに沿って一部の当事者が豊かになる可能性がある。送信者は $R$ を知ることができるので、Pay to Contract により、受信者が資金を受け取っていなくても支払いは履行されたことになる。したがって、受信者は、チャネルの取引相手から HTLC を受け取らない限り、$R$ を開示してはならない。

もしも当事者が切断された場合、取引相手は現在のコミットメントトランザクションの状態をブロックチェーンにブロードキャストする責任を負う。ブロックチェーン上では、失敗した非応答チャネルの状態だけがクローズアウトされ、他のすべてのチャネルは、チャネル内での更新を介してコミットメントトランザクションを更新し続けなければならない。したがって、取引手数料のカウンターパーティリスクは、直接チャネルのカウンターパーティにのみさらされます。もしパスに沿ったノードが応答不能になった場合、そのノードに直接接続されていない参加者は、HTLC 閉鎖前に早期決済を行わないことで、資金の時間的価値が減少するだけである。

8.2 Payment Amount

HTLC ごとに少額の支払いに使うことが好ましい。宛先までのルーティングできない場合があるため、極度に大きな額の支払いは使うべきではない。支払いが宛先まで届かず、パス上のあるノードが非協力的になっている場合、送信者は払い戻しを受け取る前に有効期限まで待つ必要がある可能性がある。配送はインターネット上のパケットのように損失が大きいかもしれないが、ネットワークはトランジット中の資金を盗むことはできない。

8.3 Clearing Failure and Rerouting

トランザクションが最終目的地に到達できなかった場合、受信者は同じハッシュで送信者に同額の支払いを送るべきであるが、$R$ を公開してはならない。ハッシュを生成した受信者は、$R$ を破棄し、決してブロードキャストしてはならない。パス上のあるチャネルがコンタクトできない場合、そのチャネルはパスの有効期限まで待つことを選択して、すべての参加者は新しいコミットメントトランザクションによる支払いなしで未払いとして HTLC を終了する可能性がある。

払い戻しルートが支払いルートと同じであり、一方の当事者が資金を盗むことができる半署名契約がない場合、HTLC に参加している最近のノードで始まる新しいコミットメントトランザクションで置き換えることによって、そのトランザクションを完全にキャンセルできる。また、支払いが反対方向に発生する（0に相殺する）代替ルートパスを作成したり、支払いパスに完全に代替ルートを作成したりして、チャネルをクリアすることもできる。これは、Lightning Network でハッシュへの入力を開示するための時間的価値のあるお金を生み出す。 参加者は、ノード間の高い接続性を専門とし、有料で他のノードからコントラクトハッシュロックをオフロードすることを提案する可能性がある。

8.4 Payment Routing

ルーティングテーブルを作るためにブロックチェーン上の 2-of-2 マルチシグの観察からそれとなくルートマップを作ることは理論的には可能である。しかし、これは pay-to-script-hash トランザクション出力では実現不可能であり、サードパーティのルーティングサービスを介して Bitcoin プロトコルから帯域外で解決可能である。最終的には、最適化により、ネットワークは、対応する銀行ネットワークまたは Tier-1 ISP によく似たものになる。自宅のネットワーク接続で宛先までどのようにパケットが届くか、ということと同様に参加者は完全なルーティングテーブルを持つ必要がない。

8.5 Fees

Lightning Network 手数料はチャネル内で直接支払う。手数料は、チャネルを所定の最大期間にわたって消費するための時間的価値と、非通信のカウンターパーティリスクに対して支払われる。当事者リスクはチャネルで直接繋がっている相手とのみ存在している。２ホップ先のあるノードが切断を決め、トランザクションをブロックチェーンにブロードキャストされると、その直接の相手はブロードキャストすべきではないが、新しいコミットメントトランザクションで更新を通してアップデートし続ける。

料金の時間的価値は、時間の消費を支払うものであり、概念的には、保管リスクのないゴールドリースレートと同等である。 それは、非常に短い期間にお金へのアクセスを使い果たすための時間価値である。 特定のパスは一方向で非常に収益性が高くなる可能性があるため、これらの収益性の高いパスでチャネルを利用できるようにするために、手数料がマイナスになる可能性がある。

9. Risks

10. Block Size Increases and Consensus

11. Use Cases

12. Conclusion

Appendix A Resolving Malleability