2
I am reading 'Mastering Bitcoin' to study for bitcoin and blockchain. At page 295-296, Author described that two parties should exchange their revocation key before signing new commitment transaction to punish when either party tries to cheat.
But, if we use this method, either party can redeem prior commitment transaction by using revocation key whenever it wants. This mechanism is being used by lightning network now. I wonder how this method prevents either party from cheating.
2
The revocation key is actually a blinded key that is calculated from the two parties' revocation basepoints and generated per commitment keys.
So for A's revocation key for a commitment, the public key is calculated from B's revocation basepoint and A's per commitment basepoint. B does the same but with A's revocation basepoint and B's per commitment. This results in a revocation public key who's secret requires a component from each party so each party individually does not know the key.
When a commitment is revoked, the two parties will exchange the per commitment secrets so they will only be able to know their respective revocation keys. Since the revocation basepoint secrets are not shared, each node cannot know the other revocation key.
The full details of the key derivation algorithm can be found here.
Thank you for answering my question. But author assumed the situation that B can punish A when B saw the prior commitment which A sent to network. It means A can use B's revocation key to return prior status. Then how can you explain this ? – xiaofo – 2018-04-13T18:41:48.490
A cannot use B's revocation key because he does not know it. I have already explained that in my answer. The process of revoking a commitment means that A reveals to B a component necessary for the revocation key; B already has the other component and A does not have access to it. – Andrew Chow – 2018-04-13T18:42:52.690
ummm... then does book have an error ? or I understand the book wrong way. then how either party can punish one ... – xiaofo – 2018-04-13T18:43:40.130
You misunderstand or you did not read it fully. At first, revocation keys are explained simply as private keys, but more details come later to fix the flaws with that approach. – Andrew Chow – 2018-04-13T18:45:11.337
Sorry. but I want to ask you only one more thing. Author said "Crucially, before signing new commitment transactions, they must first exchange revocation keys to invalidate the prior commitment" and – xiaofo – 2018-04-13T18:59:23.750
"When Irene gives Hitesh the revocation key for her prior commitment transaction, she is effectively revoking her ability to profit from regressing the channel to a prior state because with the revocation key, Hitesh can redeem both outputs of the prior commitment transaction without delay. Meaning if Irene broadcasts the prior state, Hitesh can exercise his right to take all of the outputs." Does it denote that two parties know each revocation key ? Just I failed to understand it. – xiaofo – 2018-04-13T19:01:50.620
Read further. Your question is addressed near the end of that section. – Andrew Chow – 2018-04-13T19:12:56.183
You meant that CSV is being used for that mechanism just like nLocktime is being used for usual payment channel ? – xiaofo – 2018-04-13T19:21:53.770
No, past that. Two paragraphs after the diagrams it is explained. – Andrew Chow – 2018-04-13T19:28:02.390
But there might be a lot of old commitment in a channel, so Irene or Hitesh can gather secret values and make list whenever they get secret values from each other. then they can spread prior commitment to network by using secret value from the list which they stored. – xiaofo – 2018-04-13T19:42:54.410
They can gather secret values but those values are useless because they are not the complete revocation keys. Also, the secret values used for one person's commitment are not the same ones used for the other person's commitment. – Andrew Chow – 2018-04-13T20:07:37.863
The book is not wrong, it just dumbs down things in the beginning so that you understand the concept. Things are described as they actually work later. – Andrew Chow – 2018-04-13T20:08:02.950
Okay... anyway, thank you for answering my question this far.. could you tell me explicitly which paragraph addresses my question ? I wanna read it again and again. And read the document about BOLT too. – xiaofo – 2018-04-13T20:19:57.853
"The revocation key is composed of two secrets, each half generated independently by each channel participant. It is similar to a 2-of-2 multisig, but constructed using elliptic curve arithmetic, so that both parties know the revocation public key but each party knows only half the revocation secret key." https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc after figure 8
– Andrew Chow – 2018-04-13T20:24:04.243Eng ?? That paragraph does not exist in my book. I am sure that I read all paragraphs in ‘Asymmetric Revocable Commitments’ section. I have the 2nd edition. – xiaofo – 2018-04-13T20:28:01.047
I think there is more information than book’s. I need to refer to that doc rather than book - - Thank you Andrew God, you saved me. – xiaofo – 2018-04-13T20:33:06.347
Hello, Andrew. I read the link describing about revocationpubkey. On this document, public key is calculated by own revocation basepoint and remote's per commitment point. but you explained that public key is calculated by own per commitment point and remote's revocation basepoint. Which one is right ? – xiaofo – 2018-04-14T17:52:50.297
Both are correct. You need to keep in mind the direction. In the documentation it talks about the local node creating the remote's revocation key (which goes into the commitment held by the local). My answer talks about the local node creating the local revocation key (which goes into the commitment held by the remote). My answer is more geared towards how the local generates the revocation secret. – Andrew Chow – 2018-04-14T22:13:40.003
Yeah. I noticed it. Really thank you for helping me. Now I understand of this mechanism completely. Thank you ..! – xiaofo – 2018-04-14T22:14:38.527