12

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:

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

Improve this question
1

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 3
    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
    Jul 17, 2017 at 21:47
  • 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
    Jul 17, 2017 at 21:47
  • 1
    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.
    – Andrew Chow ♦
    Jul 17, 2017 at 21:52
  • 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
    Jul 19, 2017 at 0:54
  • Updated link to official documentation: github.com/lightning/bolts/blob/master/03-transactions.md
    – user7778287
    Oct 1, 2022 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.