<p>The revocation key is actually a blinded key that is calculated from the two parties' revocation basepoints and generated per commitment keys.</p>

<p>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.</p>

<p>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.</p>

<p>The full details of the key derivation algorithm can be found <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation" rel="noreferrer">here</a>.</p>

CC BY-SA 3.0
2018-04-13T18:41:48.490Z
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
CC BY-SA 3.0
2018-04-13T18:42:52.690Z
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.
Ava Chow
CC BY-SA 3.0
2018-04-13T18:43:40.130Z
ummm... then does book have an error ? or I understand the book wrong way. then how either party can punish one ...
xiaofo
CC BY-SA 3.0
2018-04-13T18:45:11.337Z
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.
Ava Chow
CC BY-SA 3.0
2018-04-13T18:59:23.750Z
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
CC BY-SA 3.0
2018-04-13T19:01:50.620Z
"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
CC BY-SA 3.0
2018-04-13T19:12:56.183Z
Read further. Your question is addressed near the end of that section.
Ava Chow
CC BY-SA 3.0
2018-04-13T19:21:53.770Z
You meant that CSV is being used for that mechanism just like nLocktime is being used for usual payment channel ?
xiaofo
CC BY-SA 3.0
2018-04-13T19:28:02.390Z
No, past that. Two paragraphs after the diagrams it is explained.
Ava Chow
CC BY-SA 3.0
2018-04-13T19:42:54.410Z
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
CC BY-SA 3.0
2018-04-13T20:07:37.863Z
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.
Ava Chow
CC BY-SA 3.0
2018-04-13T20:08:02.950Z
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.
Ava Chow
CC BY-SA 3.0
2018-04-13T20:19:57.853Z
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
CC BY-SA 3.0
2018-04-13T20:24:04.243Z
"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
Ava Chow
CC BY-SA 3.0
2018-04-13T20:28:01.047Z
Eng ?? 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
CC BY-SA 3.0
2018-04-13T20:33:06.347Z
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
CC BY-SA 3.0
2018-04-14T17:52:50.297Z
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
CC BY-SA 3.0
2018-04-14T22:13:40.003Z
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.
Ava Chow
CC BY-SA 3.0
2018-04-14T22:14:38.527Z
Yeah. I noticed it. Really thank you for helping me. Now I understand of this mechanism completely. Thank you ..!
xiaofo
CC BY-SA 4.0
2021-03-03T08:54:09.170Z
In the last example of balance change 3 and 7, how about Hitesh cheat? I mean Hitesh gets Irene's revocation key, and immediately broadcasts this transaction to get all 10 Bitcoin immediately.
maxisacoder
CC BY-SA 3.0
2018-04-13T18:38:27.147Z
2018-04-13T18:38:27.147Z
Ava Chow
<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2020-08-13T09:26:54.850Z
The github version of the book explains things better -- https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#asymmetric_commitments
LeafGlowPath
<blockchain><lightning-network>
Asymmetric revocable commitment's revocation key
xiaofo
# Asymmetric revocable commitment's revocation key

(Asked by: username_0 on 2018-04-13)

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.

**Tags:** blockchain, lightning-network

> **Comments:**
> **username_1**: The github version of the book explains things better -- https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#asymmetric_commitments  

---

## 1 answers

### Answer by username_2 on 2018-04-13. Score: 5 | Accepted answer

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](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation).

> **Comments:**
> **username_0**: 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 ?  
> **username_2**: 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.  
> **username_0**: ummm... then does book have an error ? or I understand the book wrong way. then how either party can punish one ...  
> **username_2**: 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.  
> **username_0**: 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  
> **username_0**: "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.  
> **username_2**: Read further. Your question is addressed near the end of that section.  
> **username_0**: You meant that CSV is being used for that mechanism just like nLocktime is being used for usual payment channel ?  
> **username_2**: No, past that. Two paragraphs after the diagrams it is explained.  
> **username_0**: 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.  
> **username_2**: 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.  
> **username_2**: 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.  
> **username_0**: 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.  
> **username_2**: "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  
> **username_0**: Eng ?? 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.  
> **username_0**: 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.  
> **username_0**: 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 ?  
> **username_2**: 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.  
> **username_0**: Yeah. I noticed it. Really thank you for helping me. Now I understand of this mechanism completely. Thank you ..!  
> **username_3**: In the last example of balance change 3 and 7, how about Hitesh cheat? I mean Hitesh gets Irene's revocation key, and immediately broadcasts this transaction to get all 10 Bitcoin immediately.  

---

