<p><strong>Alice and Bob jointly create a public key R for each revocable output (RSMC output script).</strong></p>

<p>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</p>

<p>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.</p>

<p>Pre-images are used for routing (htlc output scripts) See later slides in chapter: <a href="https://teachbitcoin.github.io/payment_channels.html#/" rel="nofollow noreferrer">https://teachbitcoin.github.io/payment_channels.html#/</a></p>

CC BY-SA 4.0
2018-12-03T08:35:45.703Z
I was using pre-images as a proxy for private keys, and hashes as public keys. These are not the same as the ones used for HTLC's. I edited my question to replace "pre-image" with "ephemeral private key".
Tejaswi Nadahalli
CC BY-SA 4.0
2018-11-30T07:51:45.667Z
2018-11-30T07:51:45.667Z
James C.
<p>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. </p>

<p>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).</p>

<p>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).</p>

CC BY-SA 4.0
2019-12-08T20:54:00.430Z
Or perhaps to clearify, I believe in the protocol there is always a time when Alice has commited to state S but Bob can still choose whether he wants to cooperate and take S or stop playing and go with S-1. It's not like S-1 is a disaster for Alice afterall they both agreed to it previously. It just means that for Alice a "successful transaction" happens only after Bob also signals his acceptance by publishing his old secret (not immediately after she gets her commitment signed by him).
fiction
CC BY-SA 4.0
2019-12-08T20:15:34.263Z
2019-12-08T20:15:34.263Z
fiction
<p>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.</p>

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

<p>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.</p>

<lightning-network><channels><ln-penalty-transaction><ln-commitment-transaction>
Order of Exchanging Revocation Keys during Lightning Transactions
Tejaswi Nadahalli
# Order of Exchanging Revocation Keys during Lightning Transactions

(Asked by: username_0 on 2018-11-27)

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.

**Tags:** lightning-network, channels, ln-penalty-transaction, ln-commitment-transaction


---

## 2 answers

### Answer by username_1 on 2018-11-30. Score: 3

**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#/>

> **Comments:**
> **username_0**: I was using pre-images as a proxy for private keys, and hashes as public keys. These are not the same as the ones used for HTLC's. I edited my question to replace "pre-image" with "ephemeral private key".  

---

### Answer by username_2 on 2019-12-08. Score: 0

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).

> **Comments:**
> **username_2**: Or perhaps to clearify, I believe in the protocol there is always a time when Alice has commited to state S but Bob can still choose whether he wants to cooperate and take S or stop playing and go with S-1. It's not like S-1 is a disaster for Alice afterall they both agreed to it previously. It just means that for Alice a "successful transaction" happens only after Bob also signals his acceptance by publishing his old secret (not immediately after she gets her commitment signed by him).  

---

