前回、2ノード間での送金メッセージについて説明した。
以降は、送金にまつわるデータについて紹介していく。
今回は、commitment transactionについて解説する。
2ノード間でチャネルを解説するときにfunding transaction をブロックチェーンに展開した。
BOLTでは、その出力のcommitment transactionというトランザクションとHTLCで送金を管理している。
funding transactionの出力は、commitment transactionか、お互いが同意してチャネルを閉鎖するときのclosing transactionかのいずれかである。
同意してチャネルを閉鎖することをMutual Closeと呼ぶ。
正常に閉鎖する場合は、手数料や送金結果を最短でしようできるようになるので、Mutual Closeしてclosing transaction をブロックチェーンに展開するのがお互いにとってよい。
ただ、チャネルを解説している間に何か問題が発生して、Mutual Close の手続きができない状態になるかもしれない。その場合でも最新のcommitment transaction を展開すれば、取り戻すことができる。
そういうチャネル閉鎖のやり方を、Unilateral Closeと呼ぶ。
金額が変化するとcommitment transactionの構成が変化するので、お互いが正しいcommitment transaction を持っていることを確認するためにcommitment_signed メッセージで署名を送り合っている。
もし1satoshiでも違ったり、トランザクションのvoutの順番が違っていたりすると、署名が異なることになる。
funding transactionは2-of-2のMultiSig へ送金しているため、commitment transaction には双方が署名する必要がある。
BOLTメッセージではトランザクション本体を送りあうことはないので、署名をするのに必要なだけの情報をお互いが持っていなくてはならない。
commitment_signedでは相手にcommitment transaction の署名を送るが、これは「相手が持つcommitment transaction に自分が行った署名」を渡している。
つまり、自分では「自分が送信できるcommitment transaction」と「相手が送信するためのcommitment transaction」のデータを持ち、メッセージでは相手のための署名だけを送っていることになる。
自分の秘密鍵を相手に渡すことはないので、相手用のcommitment transaction に署名まではできるのだが、相手がそれに署名した結果をもらうことはないため、相手用のcommitment transaction は自分ではブロックチェーンに展開できないのである。
今回はcommitment transactionの位置づけと、署名のされ方について解説した。
次回はcommitment transactionの構成について説明する。