The state update order of Lightning Network when exchanging private keys and new commitment transactions

Question

I was studying Lightning Network recently and got into confusion.

I want to know that the process order of generating a new state to revoke the old state in the Lightning Network. When a new commitment transaction is generated, do the two parties firstly exchange signatures for the new transaction, and then the private key used in the previous commitment transaction is sent to the other party to revoke the previous state, or is the situation reversed? (That is, the private key is exchanged first, and then the new commitment transaction pair is signed and exchanged).

Or there is another more specific order?

Answer 1

I think this is one of the situations where a video and visualizations help more than a long text. I have explained this process in this video https://youtu.be/5YfQpMITUfI at 1:13:00 during a workshop at BTC2019 in Denver.

When the funds are updated this is done with htlcs. There is an intermediate state where the recipient of funds has two valid commitment transactions but not released the recovation secret (what you called the key). This is not an issue though as they cannot steal funds by publishing the old commitment transaction as they have a lower balance on the old one. The exact process with all the technical details is also described in bolt 2 but again I think this is one of the cases where video content is more helpful than a long text which is why I decided against writing it here again which would be similar to the part in bolt 02 anyway.

In general first the new state is created and signed an then the recovation secrets are shared

Answer 2

Or there is another more specific order?

No, the order is always the same : I receive your signature for the next commitment (commitment_signed message), then I give you my private key for revoking this one (*) (revoke_and_ack message).

What's confusing is that updates are actually done in batches and commitment transaction are not always in sync. This post by Rusty Russell is a more detailed explanation of what's happening here.

(*) Which you can only use if and only if I broadcast this transaction.