How does Lightning transaction revocation work? 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.
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
  &lt;revocation_key&gt;
OP_ELSE
 `to_self_delay`
  OP_CSV
  OP_DROP
  &lt;local_delayedkey&gt;
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/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.