<p>When you open a lightning channel, you will receive from the other person their <code>revocation_basepoint</code>, and for each commitment transaction, you will send to the other person a <code>per_commitment_point</code>. The <code>revocation_basepoint</code> has a <code>revocation_basepoint_secret</code> which is a secret key that the other person keeps to themselves. The <code>per_commitment_point</code> has a <code>per_commitment_secret</code> which you keep to yourself (for now)</p>
<p>When you create a commitment, you use the the other person's <code>revocation_basepoint</code> and your <code>per_commitment_point</code> to generate a public key, the <code>revocation_key</code>. This key is then used in a witness script which looks like this:</p>
<pre><code>OP_IF
  &lt;revocation_key&gt;
OP_ELSE
 `to_self_delay`
  OP_CSV
  OP_DROP
  &lt;local_delayedkey&gt;
OP_ENDIF
OP_CHECKSIG
</code></pre>
<p>This script is used in the <code>to_local</code> output - the the output that will pay you (after the delay) if you have to broadcast this commitment transaction. The other person has a similar <code>to_local</code> output in their commitment transaction.</p>
<p>When you go to make another commitment, you will want to revoke this previous commitment. To do so, you will send to the other person the <code>per_commitment_secret</code> that you used for this commitment. They can use that <code>per_commitment_secret</code> and their own <code>revocation_basepoint_secret</code> to derive the private key for the <code>revocation_key</code>.</p>
<p>If you were to broadcast this now-revoked commitment, the other person now has the information necessary to derive the private key for the <code>revocation_key</code>. They can then use that private key to sign a transaction which spends your <code>to_local</code> output thereby taking your coins and penalizing you for broadcasting a revoked commitment. Since you do not have their <code>revocation_basepoint_secret</code>, you cannot derive the revocation private key and thus must wait for the delay before you can spend the funds.</p>
<p>The details for the lightning specification are available here: <a href="https://github.com/lightning/bolts/blob/master/03-transactions.md" rel="nofollow noreferrer">https://github.com/lightning/bolts/blob/master/03-transactions.md</a>.  They are a little hard to read though but do explain in detail how everything in lightning is supposed to work. The spec is still being worked on so some of the things there may change.</p>

CC BY-SA 3.0
2017-07-17T21:47:39.197Z
Hmm, this answer is still pretty hard to understand. I only know what you mean by `per_commitment_point` and `revocation_basepoint` because I've been reading so much about this, but anyone that hasn't isn't going to know what those things are, or what it means for a "point" to "have" a secret.
B T
CC BY-SA 3.0
2017-07-17T21:47:45.773Z
So my understanding is that once both parties have the other party's secret, they can spend this revocation transaction *only* if the invalidated transaction is posted. My question then becomes, what prevents a misbehaving actor from spending an outdated (invalidated) commitment transaction then also spending the output of that transaction. In other words, what guarantees that the revocation transaction is posted first?
B T
CC BY-SA 3.0
2017-07-17T21:52:27.327Z
The output of a commitment transaction that spends to yourself has a timelock so if you publish the revoked commitment you will need to wait for the timeout to be up before you can spend those coins. However the other party will have the revocation key (because he has it after you agreed to revoke the commitment) and can then spend the coins from that output immediately. Nothing guarantees that the revocation transaction is posted first, but the delay guarantees that the other party will have enough time to see the revoked commitment and then create the revocation transaction.
Ava Chow
CC BY-SA 3.0
2017-07-19T00:54:28.957Z
Ohhh kay, after going back and reviewing an image that shows the transactions in detail, I see I was mistaken that the commitment transactions had an output to Alice and to Bob. This misunderstanding made it difficult to understand. Thanks!
B T
CC BY-SA 4.0
2022-10-01T08:44:31.423Z
Updated link to official documentation: https://github.com/lightning/bolts/blob/master/03-transactions.md
user7778287
CC BY-SA 4.0
2017-07-17T08:56:25.703Z
2022-10-02T02:34:25.987Z
2022-10-02T02:34:25.987Z
Ava Chow
<p>I've been reading about the Lightning Network, and I feel like I alllllmost understand it, but I can't quite figure out how the revocation transactions are designed so user A can claim the channel's bitcoins if user B tries to post an out-of-date commitment transaction. </p>

<p>From what I understand, revocation transactions (aka anti-cheat transactions) can be posted that will give the poster their bitcoins after 1 week, but will give the other party their bitcoins immediately. What I don't understand is, when an out-of-date revocation transaction is posted by user B, how user A can also claim user B's bitcoins.</p>

<p>Here are some of the best sources I've read for this:</p>

<ul>
<li><a href="https://rusty.ozlabs.org/?p=450" rel="noreferrer">https://rusty.ozlabs.org/?p=450</a></li>
<li><a href="https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/" rel="noreferrer">https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/</a></li>
</ul>

<p>I'd very much appreciate an explanation that helps this part of the protocol make sense. </p>

CC BY-SA 3.0
2017-07-19T03:46:52.743Z
related: [What is a hash pre-image as it is used for the breach remedy?](https://bitcoin.stackexchange.com/q/48053/5406)
Murch
<lightning-network><ln-penalty-transaction>
How does Lightning transaction revocation work?
B T
# How does Lightning transaction revocation work?

(Asked by: username_0 on 2017-07-17)

I've been reading about the Lightning Network, and I feel like I alllllmost understand it, but I can't quite figure out how the revocation transactions are designed so user A can claim the channel's bitcoins if user B tries to post an out-of-date commitment transaction.

From what I understand, revocation transactions (aka anti-cheat transactions) can be posted that will give the poster their bitcoins after 1 week, but will give the other party their bitcoins immediately. What I don't understand is, when an out-of-date revocation transaction is posted by user B, how user A can also claim user B's bitcoins.

Here are some of the best sources I've read for this:

* <https://rusty.ozlabs.org/?p=450>
* <https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/>

I'd very much appreciate an explanation that helps this part of the protocol make sense.

**Tags:** lightning-network, ln-penalty-transaction

> **Comments:**
> **username_1**: related: [What is a hash pre-image as it is used for the breach remedy?](https://bitcoin.stackexchange.com/q/48053/5406)  

---

## 1 answers

### Answer by username_2 on 2017-07-17. Score: 15

When you open a lightning channel, you will receive from the other person their `revocation_basepoint`, and for each commitment transaction, you will send to the other person a `per_commitment_point`. The `revocation_basepoint` has a `revocation_basepoint_secret` which is a secret key that the other person keeps to themselves. The `per_commitment_point` has a `per_commitment_secret` which you keep to yourself (for now)

When you create a commitment, you use the the other person's `revocation_basepoint` and your `per_commitment_point` to generate a public key, the `revocation_key`. This key is then used in a witness script which looks like this:

```
OP_IF
  <revocation_key>
OP_ELSE
 `to_self_delay`
  OP_CSV
  OP_DROP
  <local_delayedkey>
OP_ENDIF
OP_CHECKSIG

```

This script is used in the `to_local` output - the the output that will pay you (after the delay) if you have to broadcast this commitment transaction. The other person has a similar `to_local` output in their commitment transaction.

When you go to make another commitment, you will want to revoke this previous commitment. To do so, you will send to the other person the `per_commitment_secret` that you used for this commitment. They can use that `per_commitment_secret` and their own `revocation_basepoint_secret` to derive the private key for the `revocation_key`.

If you were to broadcast this now-revoked commitment, the other person now has the information necessary to derive the private key for the `revocation_key`. They can then use that private key to sign a transaction which spends your `to_local` output thereby taking your coins and penalizing you for broadcasting a revoked commitment. Since you do not have their `revocation_basepoint_secret`, you cannot derive the revocation private key and thus must wait for the delay before you can spend the funds.

The details for the lightning specification are available here: <https://github.com/lightning/bolts/blob/master/03-transactions.md>. They are a little hard to read though but do explain in detail how everything in lightning is supposed to work. The spec is still being worked on so some of the things there may change.

> **Comments:**
> **username_0**: Hmm, this answer is still pretty hard to understand. I only know what you mean by `per_commitment_point` and `revocation_basepoint` because I've been reading so much about this, but anyone that hasn't isn't going to know what those things are, or what it means for a "point" to "have" a secret.  
> **username_0**: So my understanding is that once both parties have the other party's secret, they can spend this revocation transaction *only* if the invalidated transaction is posted. My question then becomes, what prevents a misbehaving actor from spending an outdated (invalidated) commitment transaction then also spending the output of that transaction. In other words, what guarantees that the revocation transaction is posted first?  
> **username_2**: The output of a commitment transaction that spends to yourself has a timelock so if you publish the revoked commitment you will need to wait for the timeout to be up before you can spend those coins. However the other party will have the revocation key (because he has it after you agreed to revoke the commitment) and can then spend the coins from that output immediately. Nothing guarantees that the revocation transaction is posted first, but the delay guarantees that the other party will have enough time to see the revoked commitment and then create the revocation transaction.  
> **username_0**: Ohhh kay, after going back and reviewing an image that shows the transactions in detail, I see I was mistaken that the commitment transactions had an output to Alice and to Bob. This misunderstanding made it difficult to understand. Thanks!  
> **username_3**: Updated link to official documentation: https://github.com/lightning/bolts/blob/master/03-transactions.md  

---

