これからノード間で送金を行うための準備を行う。
送金するためには「チャネル」と呼ぶ関係を作る。
チャネルができた後は、チャネルについた識別子(channel_id)をBOLTメッセージに載せて通信をしていく。
チャネルを開設する処理を「Channel Establishment」と呼んでいる。
Channel Establishのシーケンスを以下に示す。
Channel Establishにて、on-chainからoff-chainに制御を移す。
移す際に、FunderとFundeeのMultiSig(2-of-2)に送金を行う。
その2-of-2の鍵や、不正を行わないようBitcoinのトランザクションにスクリプトを作るための鍵などがあり、それらをEstablish中に交換する。
鍵を直接交換するのでは無く、鍵を生成するための情報を交換し、各自で計算することになる。
計算については、以下を参照のこと。
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#keys
また、鍵は固定ではなく、2-of-2トランザクションの出力内容を更新するたびに新しく作り替え、古い鍵情報は廃棄(revoke)する。
送金を行った後で古い出力内容をon-chainに載せられてしまうと、Bitcoinとしてはon-chainに見える送金情報しか確認できないため、結果として行った送金が無かったことになってしまうためである。
ただ、廃棄したことを約束事だけにしてしまわず、トランザクションのスクリプトと、BOLTメッセージのルールを組み合わせることで、古い出力内容をon-chainに展開すると、展開した方が損をする、というしくみになっている。
鍵(公開鍵)は、以下の種類がある(2017/11/27現在)。
- localkey
- remotekey
- local_delayedkey
- remote_delayedkey
- local_revocationkey
- remote_revocationkey
- local_htlckey
- remote_htlckey
localとremoteがあり、お互いが作成できるだけの情報を交換する。
これらの鍵を使って、それぞれが2-of-2トランザクションからの出力(commitment transaction)を作成できるようになっている。
このように、鍵については慎重に考えられているが、ここでは、以下を認識しておけば良いだろう。
- 鍵を直接交換しないで交換した情報から生成する
- 最初の情報交換は、Channel Establish時に行う
- 2-of-2トランザクションからの出力内容(commitment transaction)が変わるたびに、鍵を作り直す
- 古い鍵を使ったcommitment transactionを使うと損する設計になっている
参照
https://github.com/nayutaco/ptarmigan/blob/development/ucoin/src/ln/ln_derkey.c