Order of Exchanging Revocation Keys during Lightning Transactions

Question

How do Alice and Bob share their ephemeral private keys simultaneously? If they don't, and let's say Alice first sends Bob her private key. At this point, Bob can broadcast his current commitment transaction, and the previous commitment transaction (as he still has not sent his previous commitment transaction's private key to Alice yet). But Alice can only broadcast her current commitment transaction, as she has sent her revocation private key of her previous commitment transaction to Bob already. This asymmetry is a bit baffling.

If the previous commitment transaction favored Bob, what prevents him from broadcasting it - knowing that Alice cannot penalize him.

My guess of an answer for this is that they share their private keys based on whether value is flowing from Alice to Bob or Bob to Alice. As in, if the previous commitment transaction favors Bob, then he has to share his private key first. Or some such.

Answer 1

Alice and Bob jointly create a public key R for each revocable output (RSMC output script).

They each privately generate r-1 and r-2, and derive public keys R-1 and R-2 from these. R is the sum of R-1 and R-2. No secrets have been exchanges, only public keys. So R is unspendable by either. However, it is spendable by r = r-1 + r-2

When a new commitment tx is created, this RSMC must be revoked. If the new tx commitment favors Bob, then Alice must share r-1 with Bob. Now bob knows that he can spend this revoked output if Alice broadcasts it. Bob doesnt need to share r-2 with Alice as he would rather broadcast the subsequent tx favoring him.

Pre-images are used for routing (htlc output scripts) See later slides in chapter: https://teachbitcoin.github.io/payment_channels.html#/

Answer 2

There is no timing issue. AFAIK a simplified algorithm is basically just after you get a new commitment signed from the other side you can safely reveal the secret for your previous commitment. Trick is that state in lightning is asymmetric and Alice's commitment 1 is different than Bob's commitment 1.

The breach remedy is always "other side + my secret" (so in case of hash you can imagine you need signature of other side + preimage in case of ephemeral key it is similar the one who generated the secret can still not generate the complete key).

Say Alice gets her new commitment signed by Bob. There is no reason for Alice to use any of her old commitments anymore (as Bob could punish her for doing so). Of course Bob could now still publish the previous commitment that Alice once signed (his latest version). But that is a bit schizophrenic (he just signed that he agrees to a new state and now he wants to run away). If he does there could be a race - Alice can immediately publish her version and effectively just one will win (as both spend the 2-of-2 multisig). So state updates are not atomic, when S is proposed the other side can still bail-out with S-1, but once both commit to S there is no way back). Also if you wouldn't play by the protocol rules and publish wrong secret that can be detected and other side can try to close channel with state S-1 (it might end up with S but not with any other outcome like S-2 for sure).