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
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:
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
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/lightningnetwork/lightning-rfc/. 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.