Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
288 lines (176 sloc) 32.5 KB

The Bitcoin Lightning Network

Scalable Off-Chain Instant Payments

Joseph Poon - joseph@lightning.network
Thaddeus Dryja - rx@awsomnet.org
January 14, 2016
DRAFT Version 0.5.9.2

Original Paper

Abstract

1 The Bitcoin Blockchain Scalability Problem

2 A Network of Micropayment Channels Can Solve Scalability

...

現状のマイクロペイメントとスケーラビリティの解決策は、第三者である管理業者(Custodian)に自分のコインと他者との残高の更新を信託することで、管理業者にトランザクションをオフロードすることである。第三者に全ての資産を信託することは、取引先リスクと取引コストの面で不利益が生じる。

...

2.1 Micropayment Channels Do Not Require Trust

...

もし、チャネル上の残高が [Alice:0.05, Bob:0.05]であり、取引後の残高が[Alice:0.07, Bob:0.03]である場合、ネットワークはどっちの残高が正しいのか知る必要がある。

...

それと同時に、ネットワークに流すとコスト高となり得るため、本当に必要なとき以外はブロックチェーンのタイムスタンプを使わないシステムが望まれる。

その代わり、双方はトランザクションへの署名とこのブロードキャストしないことに合意することができる。 もし双方が、2-of-2マルチシグアドレスに送金するトランザクションを作ったならば、これは現在の残高に対する合意となる。 双方はこの2-of-2トランザクションから自分自身へ0.05返金可能であることに合意したことになる。 この返金トランザクションはブロードキャストしない ただ、双方とも、それをブロードキャストするのが望ましいと感じた時はいつでもそうできる ブロードキャストを先延ばしにしている間は、双方は将来この拠出金の残高を変更することに合意しているとみなせる

この残高を更新するには、例えばAlice: 0.07, Bob:0.03など、双方が2-of-2マルチシグアドレスに対する新しい支出を作成すればよい。 にも関わらず、適切に設計しなければ、新しい支出と元々の返金どちらが正しいのか知るよしがないというタイムスタンプ問題が生じる。

とはいえ、タイムスタンプと日付の制限は、Bitcoinのブロックチェーンにある全てのトランザクションの完全な順序づけほど複雑ではない。 マイクロペイメントチャネルでは次の2つの状態〜現在の正しい残高とすでに失効した残高〜だけが必須となる。そこには単一の現在の正しい残高と、おそらく多くの失効した過去の残高がのみ存在することになるだろう。

これは、全ての古いトランザクションを無効にし、新しいトランザクションのみが有効とするスクリプトを考案することにより、可能となる。 無効化は、Bitcoinのアウトプットスクリプトと、他者が双方の拠出額の全てをチャネルの相手方に送付できるような依存トランザクションにより行われる。

...

2.2 A Network of chanels

このように、マイクロペイメントチャネルは2者間に関係を作るだけである。全ての人が他の全てとチャネルを作らないといけないのであればスケーラビリティの問題は解決しない。Bitcoinのスケーラビリティ問題はマイクロペイメントチャネルの巨大なネットワークを使うことによって実現できる。

...

3 Bidirectional Payment Channels

マイクロペイメントチャネルにより、あるトランザクション状態のブロードキャストを未来に延期できる。 すなわち、一方の当事者に対して、未来の定められた日の前後にトランザクションをブロードキャストする責任を負わせられるようになる。 ブロックチェーンは一種の非中央集権型タイムスタンプシステムであるため、現在の状態を一連の出来事を順序付ける手段として使えるだけでなく、データ妥当性の決定するための非中央集権型コンセンサスの構成要素である時計も利用することができる。

ブロードキャストとその無効化が可能な特定の状態を持つタイムフレームを構成することにより、Bitcoinのトランザクションスクリプトを利用した複雑なコントラクトを作成することができる。すでにハブアンドスポーク型マイクロペイメントチャネル(およびトラステッドペイメントチャネルネットワーク)については先行研究されており、実際にハブアンドスポーク型のネットワークが構築された実例もある。 しかしながら、ライトニングネットワークの双方向型マイクロペイメントチャネルは、中間ノードの破綻リスクを軽減して無限に近いスケーラビリティを実現するものであり、付録Aに記載したマリアビリティソフトフォークを必要とする。

複数のマイクロペイメントチャネルの相互接続によって、トランザクション経路のネットワークを作ることが可能になる。 各経路がBGPのようなシステムでルーティングできれば、送信者は受信者への特定の経路を選べるようになるかもしれない。 出力スクリプトは受信者によって生成されたハッシュにより撹乱される。 このハッシュへの入力を明らかにすることにより、受信者の相手方はルートに沿って資金を引き出すことが可能になる。

3.1 The Problem of Blame in Channel Creation

前述のペイメントネットワークに参加するためには、当事者がネットワーク上の他の参加者との間にマイクロペイメントチャネルを作る必要がある。

3.1.1 Creating an Unsigned Funding Transaction

最初のチャネル出資トランザクションは、このトランザクションの入力へのチャネルの片方または双方の当事者の資金によって作られる。両当事者はこのトランザクションの入力と出力を作るが、これに署名はしない。

この出資トランザクションのアウトプットは、チャネルの双方の参加者(以下、AliceとBobとする)による単一の2-of-2マルチシグスクリプトである。元々の出資額をそれぞれの出資者に償還するために、2-of-2アウトプットから支出を作成する必要が生じるまでの間、双方の参加者は出資トランザクションの署名を交換しない。

出資トランザクションに署名しない目的は、一方の当事者がまだ存在しないトランザクションから支出することを可能にするためである。 もしAliceとBobが、出資トランザクションからの支出をブロードキャストしないまま、その出資トランザクションの署名を交換した場合、 AliceとBobが協力しなければと資金は永遠にロックされる(もしくは一方の当事者の相手方の協力に対する支払を人質として、他のコインを損失することになるかもしれない)。

AliceとBobの双方が(どちらのインプットがチャネルの総額を表しているのかを知るため)出資トランザクションへのインプットを交換し、さらに後々署名する際に使う一方の鍵を交換する。この鍵が出資トランザクションの2-of-2アウトプットに対して使われる。それは出資トランザクションを遣うには双方の署名が必要となるためである。言い換えると、出資トランザクションを遣うには、AliceとBobの双方の合意が必要ということである。

3.1.2 Spending from an Unsigned Transaction

まだ署名が取り交わされていないトランザクションから支出する時に必要となるSIGHASH_NOINPUTトランザクションを、ライトニングネットワークでは2-of-2の出資トランザクションのアウトプットを支出するために使う。ソフトフォークとして実装されているSIGHASH_NOTINPUTは、当事者全員の署名が完了する前にトランザクションを支出できるようにするものであり、トランザクションは新しいsighashフラグ付きでないIDを取得するために署名されている必要がある。

SIGHASH_NOINPUTが存在しなければ、Bitcoinのトランザクションはブロードキャストする前に支出できない。これはつまり、他の当事者に対して先に支払を済ませなければ契約書を起草できないようなものである。SIGHASH_NOINPUTはこの問題を解決するためにある。詳しくは付録Aに実装内容とともに記載した。

出資トランザクションを消費するには、子となるインプットの署名に含まれる(出資トランザクションの)トランザクションIDが必要となるため、SIGHASH_NOINPUTが存在しなければ、(出資トランザクションのような)署名を交換していないトランザクションを消費するトランザクションは生成できない。トランザクションIDの構成要素には、親(つまり出資)トランザクションの署名が含まれるため、両当事者は、子トランザクションによる消費に先立って、あらかじめ親に対するそれぞれの署名を交換することが(通常は)求められる。つまり、親を消費するには、少なくともどちらかの当事者が親の署名を知らなければならず、それはどちらかの当事者が、子がまだ存在する前に親(つまり出資トランザクション)をブロードキャストできるということを意味する。SIGHASH_NOINPUTは、(親の)インプットへの署名抜きで子による支出を認めることによって、この問題を回避するものである。SIGHASH_NOINPUTによる(トランザクション作成の)手順は以下のとおりである。

  1. 親(つまり出資トランザクション)を作成する
  2. 子(つまり確定トランザクションとこの確定トランザクションからの全ての支出)を作成する
  3. 子に署名する
  4. 子の署名を交換する
  5. 親に署名する
  6. 親の署名を交換する
  7. 親をブロックチェーン上ににブロードキャストする

ステップ6が完了するまで、誰も親をブロードキャストすること(ステップ7)はできない。両当事者は、 ステップ6まで出資トランザクションの支出するために必要な署名を、どちらからも与えられていないのである。さらに、一方の当事者がステップ6に至るまでに離脱した場合、親は(そのまま)親トランザクションとして支出されるか、さもなくば親トランザクションへの入力(として指定されたUTXO)の二重使用となる(その場合、関連する全てのトランザクションの流れが無効となる)。

3.1.3 Commitment Transactions: Unenforcible Construction

未署名(かつ未ブロードキャスト)の出資トランザクションが生成された後、両当事者は初期の確約トランザクション(Commitment Transaction)に署名してそれを交換する。これらの確約トランザクションは、出資トランザクション(親)の2-of-2アウトプットの支出にあたる。しかしながら、ブロックチェーン上にブロードキャストされるのは、出資トランザクションのみである。

その(出資トランザクションの)アウトプットは支出の際に両当事者の合意を必要とする2-of-2マルチシグトランザクションであるため、出資トランザクションがブロックチェーンに取り込まれた後に、現在の残高を表すものが確約トランザクションとなる。

ほんの一つの2-of-2署名済み確約トランザクションが両当事者の間で交換されただけで、両当事者は、出資トランザクションがブロックチェーンに取り込まれた後に自分のお金を取り戻せるという確信が得られる。両当事者はチャネルの現保有残高の確定を望むまで、確約トランザクションをブロックチェーン上にブロードキャストしない。 当事者は現時点の確約トランザクションのブロードキャストによりそれ(保有残高の確定)を実行する。

確約トランザクションにより、各自の現保有残高がそれぞれの当事者に支払われる。単純な(ラフな)実装では、チャネルの相手方どちらにも全ての現保有残高を返すような2つのアウトプットをもつ単一のトランザクションを前提に、そこから2-of-2(マルチシグ)にて支出する未ブロードキャストのトランザクションを生成してしまう。このトランザクションは、初期の確約トランザクションを生成した際の元々の出資者に全ての出資金を返す役割を果たす。

図1

図1: この図は脆くラフな出資トランザクションを示したものである。緑で示した出資トランザクション(F)は、他の全ての(子)トランザクションへの署名がなされた後にブロードキャストされる。この出資トランザクションを使う他のすべての(子)トランザクションは、相手方が保有残高の更新を望む場合に備えてすぐにはブロードキャストしない。この時点では、出資トランザクションのみがブロックチェーン上にブロードキャストされる。

例えばAliceとBobが、1.0BTC(互いの0.5BTCずつの拠出に基づく)を支出するような単一の2-of-2(マルチシグ)アウトプットを持つ出資トランザクションの作成に合意したとすれば、彼らはAliceとBobに対する0.5BTCのアウトプット2つで構成される確約トランザクションを作るだろう。作成された確約トランザクションは先に署名されかつ(公開)鍵も交換されているため、当事者のどちらでも、出資トランザクションがブロックチェーンに取り込まれることを条件に、確約トランザクションをいつでもブロードキャストできる。ここで大事なのは、出資トランザクションの署名は安全に交換可能であり、当事者のどちらもでも、確約トランザクションのブロードキャストにより両者の出資を償還することが可能だということである。

しかしながら、当事者の一方が現保有残高を更新したいと望む場合、この構造は崩れる。保有残高を更新するために、当事者は(出資トランザクションはすでにブロックチェーンに取り込まれ、変更できないので)確約トランザクションのアウトプットの値を更新しなければならない。

両当事者が、新しい確約トランザクションに合意しかつその署名を交換する場合、どちらの当事者も確約トランザクションをブロードキャストできる。

出資トランザクションのアウトプットは一度だけしか償還できないので、有効となる確約トランザクションも一つだけである。例えば、 チャネルの保有残高が現在Aliceは0.4でBobは0.6であると両者合意しており、かつそれを反映した新しい確約トランザクションが作成されている場合、(新旧)どちらの確約トランザクションもブロードキャスト可能である。実際のところ、両当事者がお互いの保有残高をブロードキャストするために署名しかつそれを交換した以上は、当事者の一方が確約トランザクションのブロードキャストを妨げることはできない。

図2

図2: いずれの確約トランザクションとも各当事者の望むタイミングでブロードキャストできるが、一つしかない出資トランザクションを使えるのはどちらか一方のみである。この方法は、当事者の一方が直近のトランザクションのブロードキャストを望まない場合には上手くいかない。

新しい確定トランザクションが生成された結果、いずれの当事者も確定トランザクションのブロードキャストを許されるため、少ない出資金を受け取る当事者は、そのアウトプットが自身にとってより多くの価値をもつ確約トランザクションをブロードキャストする強いインセンティブを持つことになる。 この結果として、チャネルはすぐさまクローズされ、出資金が盗難されてしまう。それ故、このモデルの下では、ペイメントチャネルの生成はままならない。

3.1.4 Commitment Transactions: Ascribing Blame

署名された確定トランザクションはいずれもブロックチェーン上にブロードキャストできてしまうため、どちらか一方しかブロードキャストに成功しなかったとしても、古い確定トランザクションがブロードキャストされることを防ぐ必要がある。 (とはいえ)Bitcoinの非常に大量のトランザクションを無効にすることは不可能であり、なんらか他の方法が求められる。 ブロックチェーンによる積極的な無効化を強制する代わりに、両当事者の確約に従い、かつそれを反故にした際にはペナルティが課せられるという、信用保険に近いマナーに則ってチャネル自体を構築する必要がある。 もし一方の当事者が契約に違反した場合、両者はチャネルの全ての額を失うことになる。

このようなペイメントチャネルでは、直近のトランザクションのみをブロードキャストするという両当事者による合意が契約条件となる。 直近よりも古いトランザクションのブロードキャストはいずれも契約違反を引き起こすため、全ての出資はペナルティとしてそれぞれの相手方に分配される。

これは、一方の当事者に古いトランザクションをブロードキャストする責任を帰すことができる場合のみ執行できる。 このためには一方の当事者が、古いトランザクションをどちらがブロードキャストしたのかをユニークに特定できなければならない。 これは当事者双方が、相手方をお互いにユニークに特定できる確約トランザクションが手元にあれば可能である。 この確約トランザクションは、ブロードキャストする責任が相手方にあることを示すため、インプットに両当事者の署名が必要である。 相手方による署名済みの確約トランザクションのバージョンの一つを手元に持ち、かつその確約トランザクションが自分の作成したバージョンである場合に限り、ブロードキャストすることができる。

ライトニングネットワークにおいて、出資トランザクションのアウトプットからのすべての支出――つまり確約トランザクション――は、2つの半署名済のトランザクションから構成される。一方の確約トランザクションはAliceが署名してBobへ渡したもの(C1b)であり、もう一方はBobが署名してAliceに渡したもの(C1a)である。これらの2つの確約トランザクションは同じアウトプット(出資トランザクション)からの支出であり、かつ異なる内容をもつため、一方の当事者しかブロックチェーンにブロードキャストすることができない。そうでなければ、双方の確約トランザクションが同じ出資トランザクションを2重使用してしまうことになる。いずれの当事者も、受け取った確約トランザクションについて、それに自身が署名しかつ相手方の署名を含めることにより、ブロードキャストできる。例えば、Bobが確約トランザクションC1bに対する署名をAliceからすでに受け取っているのであれば、彼はC1bをブロードキャストすることができる――その際にBobは(C1bに)Aliceの署名を含め、そして自らC1bへ署名する。 その(確約)トランザクションは、AliceとBob双方の署名を必要とする出資トランザクションの2-of-2出力からの有効な支出となる。

図3: 紫色のボックスはAliceがブロードキャスト可能な、未ブロードキャストのトランザクションである。青色のボックスはBobがブロードキャストキャスト可能な、未ブロードキャストのトランザクションである。Aliceは確約トランザクション1aのみをブロードキャストでき、Bobは確約トランザクション1bのみをブロードキャストできる。一つの確約トランザクションのみが出資トランザクションの出力から支出できる。責任は帰されるものの、どちらか一方

しかしながらこうした構造でも、単に一方の当事者の責任の所在を示すだけである。まだ、Bitcoinブロックチェーンにおいてこの契約を執行するには至らない。Bobは、Aliceが古いトランザクションをブロードキャストしないことを信じるしかないのだ。現時点では、半署名済みのトランザクションを証拠に、AliceがブロードキャストしたことをBobが証明できるに過ぎない。

3.2 Creating a Channel with Contract Revocation

コントラクトの条項を実際に執行可能にするためには、(支出するだけでなく)一方の当事者がトランザクションを取り消せるように確定トランザクションを構築する必要がある。この取り消しは、トランザクションがブロックチェーンに取り込まれるタイミングに関するデータおよびトランザクションの満期日を利用して、妥当性検証の道筋を明らかにすることにより達成できる。

3.3 Sequence Number Maturity

Mark Freidenbachは、ソフトフォーク[12]によって親トランザクションの相対ブロック満期(relative block maturity)を導入し、シーケンス番号に効力を持たせることを提案している。 これにより、送金スクリプトの相対ブロック承認時間ロック(relative block confirmation time lock)の幾つかの形式を保証するための基本的な能力が得られる。 さらに、OP_CHECKSEQUENCEVERIFY[13](OP_RELATIVECHECKLOCKTIMEVERIFYとしても知られる)[14]というオペコードを追加することで、トランザクションの可塑性(malleability)の恒久的な解決方法が実現するまでのつなぎ対応ができるなど、さらなる能力を得ることができる。 この論文の将来のバージョンでは、解決方法の提案も含めるつもりである。

端的に言うと、Bitcoinには、未承認トランザクション用のmempool内で利用されることだけを想定したシーケンス番号が実装されている。 その元来の目的はトランザクションの置換、つまりmempool内にあるトランザクションよりもシーケンス番号の大きなトランザクションを受信した場合に、それらをより新しいものと交換できるようすることにあった。 トランザクションの置換ルールのおかげで、 DoS攻撃のリスクを回避できるのだ。 シーケンス番号の目的からすると、ブロードキャストされていないトランザクションを置換することも意図しているように思える。 しかしながら、この用途にはシーケンス番号の置換ルールは適用されない。 mempool内のトランザクションの古いバージョンが置換され、ブロックに最新バージョンのトランザクションが含まれているということを、一方の当事者が保証することはできないのだ。 トランザクションのバージョンをチェーン外で強制する一つの方法が、時間の確約である。

無効化可能なトランザクションは、一意の型の出力スクリプトを持つトランザクションの、一意の出力部分から作ることができる。 この親の出力部は2つの償還方法――1つ目は即座に償還することができ、2つ目は子のトランザクションが最小限のブロック数を経過している場合のみに償還できる――を持つ。 これは、子トランザクションのシーケンス番号に親から最小限のブロック数の経過を要求することにより実現される。 重要なのは、この新しいシーケンス番号(を使った制御方法)の振舞いは、このアウトプットと償還のためのトランザクションとの間に存在するブロックの数が指定されたブロック高以上であるときのみに、このアウトプットからの送金を正当化できるという点である。

このシーケンス番号の振舞いにより、シーケンス番号に定義されたある定められたブロック数から制約の生成することで、トランザクションを無効化でき、親がブロックチェーンに取り込まれた時点からある定められたブロック数の間だけその送金を有効にできるというその結果を生む。 これにより、当該アウトプットを持つ親トランザクションを(無効化されていないことを証明できる)確実なデポジットとして扱える構造が形成される。 そのトランザクションがブロードキャストされた直後から、ブロックチェーンに参加する誰もが送金を伝搬することを通じて、この表明〔デポジット?〕に対する意義を唱えられる期間が存在することになる。

ここで、一方の当事者が1000ブロックの遅延を伴う無効化可能なトランザクションを作ろうとしても、出力トランザクションの構造は相変わらず次のような2-of-2のmultisigのままだろう:

2 <Alice1> <Bob1> 2 OP_CHECKMULTISIG

しかし、子となる送金トランザクションは、1000というnSequenceの値を含むことになる。 このトランザクションは正当性を証するために当事者双方の署名が必要となるので、両当事者はnSequence数を1000としてこれを署名の一部に含める。 両当事者は、――それぞれの裁量次第だが――nSequence番号を持たないもう一つ別のトランザクションを作ることを同意してもよい。 この構造(Revocable Sequence Maturity Contract: RSMC)により、非常に明快な契約条件を伴う2つの手順が生み出される。 その契約条件は以下の通りである:

  1. すべての当事者は、この契約を施行するアウトプットによりコントラクトへの〔資金の〕送金を行う。
  2. 両当事者は、一定の待機期間(スクリプト例では1,000ブロック)中であれば、〔他の〕幾つかのコントラクトへ資金を送ることもできる。
  3. 一方もしくは両方の当事者は、その資金の償還を、将来のある日付までブロードキャストしないことを選択することができる。無論、どちらか一方の当事者は、待機期間を過ぎればいつでも資金を償還できる。
  4. もし、いずれの当事者も(資金を償還する)このトランザクションをブロードキャストしていない場合、両当事者の合意に基き、後継となる送金トランザクションにおいて新しく資金の償還条件を定めることにより、前述の償還を取り消せる。 この新しい送金トランザクションは、コントラクトが(ブロックチェーン上でブロードキャストにより)全世界に開示された後であれば、直ちに履行が可能である。
  5. コントラクトが開示されており、構造が出来上がっていない場合、いずれの当事者も先に取り消しされた償還を履行できる(そのため、新しい条件の強制については、いずれの当事者も責任を追う)。

事前に署名された子トランザクションは、親トランザクションがブロックチェーン上で1,000回承認された後に、親を使用する子のインプットに含まれるnSequence番号により、履行できる。

この署名された子トランザクションを無効化するためには、両当事者は(いつでも使えるできるようになる特殊な振舞を持たせるため)nSequence番号を最大値に設定した新しい子トランザクションを、単に作成するだけでよい。

この新しい署名された送金は、その親がブロックチェーンに取り込まれてから1,000ブロック以内に(その送金が)ブロックチェーンに取り込まれる限り、その無効化可能な送金を引き継ぐ。 実際には、もしAliceとBobが確定トランザクションの誤ったブロードキャストについてブロックチェーン上でモニタすることに合意するならば、その(確定)トランザクションがブロードキャストされた瞬間に、両者はその引き継がれたトランザクションによって即座に送金を実行できる。 無効化可能な送金(使用できないトランザクション)をブロードキャストするためには、それを引き継ぐトランザクションと同じアウトプットを使用しているが故に、両当事者は1,000回承認されるまで待たなければならない。 両当事者がブロックチェーンを監視している限り、一方の当事者が引き継がれたトランザクションの方を望ましいと思えば、その無効化可能な送金がトランザクションに取り込まれることはないのである。

このような構造により誰でもトランザクションを作成することができ、そのトランザクションを〔現時点で〕ブロードキャストしないというだけでなく、ペナルティを通じて将来に向かってブロードキャストを抑止するインセンティブを与えることになる。 これにより、ビットコインネットワークの参加者は、多くのトランザクションのブロックチェーンへの取り込みを延期させられるようになる。

3.3.1 Timestop

3.3.2 Revocable Commitment Transactions

3.3.3 Redeeming Funds from the Channel: Cooperative Counterparties

3.3.4 Creating a new Commitment Transaction and Revoking Prior Commitments

3.3.5 Process for Creating Revocable Commitment Transactions

3.4 Cooperatively Closing Out a Channel

3.5 Bidirectional Channel Implications and Summary

4 Hashed Timelock Contract (HTLC)

4.1 Non-revocable HTLC Construction

4.2 Off-chain Revocable HTLC

4.3 HTLC Off-chain Termination

4.4 HTLC Formation and Closing Order

5 Key Storage

6 Blockchain Transaction Fees for Bidirectional Channels

7 Pay to Contract

8 The Bitcoin Lightning Network

8.1 Decrementing Timelocks

8.2 Payment Amount

8.3 Clearing Failure and Rerouting

8.4 Payment Routing

8.5 Fees

9 Risks

9.1 Improper Timelocks

9.2 Forced Expiration Spam

9.3 Coin Theft via Cracking

9.4 Data Loss

9.5 Forgetting to Broadcast the Transaction in Time

9.6 Inability to Make Necessary Soft-Forks

9.7 Colluding Miner Attacks

10 Block Size Increases and Consensus

11 Use Cases

12 Conclusion

13 Acknowledgements

Appendix A Resolving Malleability

References