今回はcommitment transactionの構成について説明する。
トランザクションの構成は、BOLT3に記載されている。
- version : 2
- locktime : obscured commitment transaction number
- txin : 1
- txout : n
トランザクションのINPUTは1つで、funding transactionである。
OUTPUTは、状況によって異なる。
自分が展開できるcommitment transactionを眺めた場合、fundingした資金のうちの自分の取り分と相手の取り分がある。
これがそれぞれ、to_local outputとto_remote outputになる。
それ以外には、HTLCがある。
自分から相手に送金したOffered HTLC outputsと、相手から自分に送金されたReceived HTLC outputsである。
to_remote outputはP2WPKHへの送金なので、commitment transactionを展開するとすぐに相手が使用できるが、それ以外はスクリプトへの送金になるため、スクリプトを解けなくては使用できない。
to_local outputのスクリプトは自分が持つ鍵情報だけで解くことができるのだが、Establish Channel時に相手からもらった to_self_delay を組み込むことになっている。
例えば、to_self_delayが40だった場合、to_local outputを解くためにはcommitment transactionが展開されてから40ブロック以上待たなくてはならない。
もし、<revocationkey>(公開鍵)の秘密鍵revocationsecretkeyを持っているならば、それで署名してOP_IFのルートでスクリプトを解くことができ、その場合は待ち時間はない。
ただ、revocationsecretkeyの計算にはそのスクリプトを展開した人のper_commitment_secretという情報と、相手の人のrevocation_basepoint_secretという情報が必要になっている。
per_commitment_secretは、revoke_and_ackメッセージで過去の分を交換するが、revocation_basepoint_secretについては交換しない。
そのため、revocationsecretkeyはcommitment transactionを展開した人は作成できないが、その相手は作成できることになる(ただし、過去にrevoke_and_ackメッセージで交換したものに限る)。
こうすることで、過去のcommitment transactionを展開すると相手に奪い取られるようになっている。
Offered HTLC outputsは、支払った側が作るoutputである。
つまり、update_add_htlcメッセージを送信した人はcommitment transactionにOffered HTLC outputを追加していく。
スクリプトの作りが複雑だが、通常は5行目のOP_ELSE内の方が処理される(最初のOP_IFは、廃棄したcommitment transactionを展開されたときのルート)。
自分がcommitment transactionを展開した場合は7行目(A)のOP_NOTIFのルート、そうでない場合は10行目(B)のOP_ELSEのルートになる。
7行目(A)を通る場合はHTLC-Timeout transactionへの出力、10行目(B)を通る場合はpayment_preimageを持っている場合だけ解くことができる。
送金した人(＝Offered HTLC outputsを持つ)がcommitment transactionを展開したとする。
そのHTLCは、通常は相手が受け取るはずで、受け取るときにはpayment preimageという領収書のIDが必要になる(送金(2)参照)。これはBのルート。
もし相手が受け取らないままタイムアウトを迎えた場合は、送金した人が取り戻す。こちらはAのルートである。
同じ”Offered HTLC outputs”という名称でも、どちらがcommitment transactionを展開したかによって見方が変わることに注意していただきたい。
Received HTLC outputsはその逆で、相手からupdate_add_htlcメッセージを受信した人が自分のcommitment transactionに追加することになる。
Offered HTLC outputsと似て、通常は5行目のOP_ELSE内を通る。
8行目(C)のOP_IF内は自分がcommitment transactionを展開し、payment preimageを持っている場合のルート。
12行目(D)のOP_ELSE内は相手がcomitment transactionを展開したときのルート。
着金した人(＝Received HTLC outputsを持つ)がcommitment transactionを展開したとする。
そのHTLCは通常は自分が受け取るはずで、それにはpayment preimageが必要になる(Cのルート)。
もし自分がpreimageを取得できないままタイムアウトした場合は、相手が取り戻す(Dのルート)。
これらのoutputは、送金額が決められた値以下の場合は取り除かれることになっている。
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
通常のBitcoinであれば546satoshisだが、それとは別にopen_channelやaccept_channelのdust_limit_satoshisで指定できる。
指定できるといっても、最終的にはBitcoinのブロックチェーンに展開することになるので、Bitcoinの制約を下回ることはできない。
commitment transactionについては、ここまでとする。
スクリプトが複雑なので、興味がある方は動きを確認することをお勧めする。
commitment transaction自体にはP2WPKH/P2WSHだけしか見えず、実際にスクリプトがトランザクションに現れるのは送金先トランザクションである。
次回は、その送金先トランザクションについて説明していく。