<blockquote>
  <p>An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken?</p>
</blockquote>

<p>The elliptic curve trickery you mentioned is elliptic-curve multiplication. And yes, you need to store all old values.</p>

<p>In BOLT-03, under <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation" rel="nofollow noreferrer">Key Derivation</a>, it gives three reasons why the keys are changed(<code>localpubkey</code>, <code>remotepubkey</code>, <code>local_delayedpubkey</code> and <code>revocationpubkey</code>), and one of them is related to your question,</p>

<blockquote>
  <p>Changing the <code>localpubkey</code> every time ensures that commitment transaction ID cannot be guessed except in the trivial case where there is no <code>to_local</code> output, as every commitment transaction uses an ID in its output script.</p>
</blockquote>

CC BY-SA 4.0
2019-12-10T08:36:11.100Z
2019-12-10T08:36:11.100Z
yyforyongyu
<p>I think the reason is that the authors had watchtower services in mind. Which I guess people agree are needed in the poon dryja channel construction. When you use the same keys for commitment transaction watchtower services can basically learn which payments in which amounts go through the channels. And start an attack on the privacy of people making and receiving payments. However if the keys change the channels get obfuscated for the watchtower since the state gets decorolated. </p>

CC BY-SA 4.0
2019-12-06T23:42:23.350Z
But aren't watchtowers completely blind in this regard? Yeah, they need to get that there was a new commitment immediately. But they don't actually see the stuff itself. You kind of just give them first half of the txid and tell them if you see something like this use the other half to unlock my prepared punishment and send it out. And they will see then if there is something in for them and do it. Or do you somehow need to prove to them that it is worth storing the data beforehand?
fiction
CC BY-SA 4.0
2019-12-10T09:14:19.773Z
I don't think that's the case. As @fiction was commenting the towers are blind in this regard except when there's a channel breach. To my understanding, the main reason behind using different keys is to obfuscate the state in case of a breach, independently of whether there is any tower or not.
sr_gi
CC BY-SA 4.0
2019-12-11T06:52:08.500Z
Might be related: https://bitcoin.stackexchange.com/questions/91437/if-a-user-recovered-data-directory-of-ln-node-software-with-an-old-backup-what/
Chris Chen
CC BY-SA 4.0
2019-12-06T23:18:27.763Z
2019-12-06T23:18:27.763Z
Rene Pickhardt
<p>In the paper BIP32 and deterministic key derivation are mentioned. But why given that two peers directly exchange messages (i.e., there is no need to obscure anything)? Alice always exchanges state with Bob and that commitment transactions usually don't land on the blockchain.</p>

<p>Punishments for transmitting an old state can be done by attaching to the previous "breach-remedy" transaction using a valid preimage (that was exchanged while getting the new "commitment"). This means the script has to check the signature and invoke the hash function. An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken? I've heard about ELKREM and optimizations in that part. But my question here is more basic, why did Poon and Dryja even consider BIP32? I understand the need for different settlement keys in Eltoo or the additional privacy for on-chain transactions, but what about Lightning?</p>

CC BY-SA 4.0
2019-12-06T22:20:28.517Z
I can come up just with one hypothetic case. Suppose Bob is cheating and publishes an old "commitment". Then Alice punishes him, but in a way that people monitoring the blockchain cannot see that Alice who gets money immediately and the Alice that gets the "punishment reward" is the same entity. So in some sense you hide from the public that Bob was cheating.
fiction
<lightning-network><ln-commitment-transaction>
Lightning - why are commitment transactions supposed to use different keys
fiction
# Lightning - why are commitment transactions supposed to use different keys

(Asked by: username_0 on 2019-12-06)

In the paper BIP32 and deterministic key derivation are mentioned. But why given that two peers directly exchange messages (i.e., there is no need to obscure anything)? Alice always exchanges state with Bob and that commitment transactions usually don't land on the blockchain.

Punishments for transmitting an old state can be done by attaching to the previous "breach-remedy" transaction using a valid preimage (that was exchanged while getting the new "commitment"). This means the script has to check the signature and invoke the hash function. An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken? I've heard about ELKREM and optimizations in that part. But my question here is more basic, why did Poon and Dryja even consider BIP32? I understand the need for different settlement keys in Eltoo or the additional privacy for on-chain transactions, but what about Lightning?

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

> **Comments:**
> **username_0**: I can come up just with one hypothetic case. Suppose Bob is cheating and publishes an old "commitment". Then Alice punishes him, but in a way that people monitoring the blockchain cannot see that Alice who gets money immediately and the Alice that gets the "punishment reward" is the same entity. So in some sense you hide from the public that Bob was cheating.  

---

## 2 answers

### Answer by username_1 on 2019-12-10. Score: 1 | Accepted answer

> An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken?

The elliptic curve trickery you mentioned is elliptic-curve multiplication. And yes, you need to store all old values.

In BOLT-03, under [Key Derivation](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation), it gives three reasons why the keys are changed(`localpubkey`, `remotepubkey`, `local_delayedpubkey` and `revocationpubkey`), and one of them is related to your question,

> Changing the `localpubkey` every time ensures that commitment transaction ID cannot be guessed except in the trivial case where there is no `to_local` output, as every commitment transaction uses an ID in its output script.


---

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

I think the reason is that the authors had watchtower services in mind. Which I guess people agree are needed in the poon dryja channel construction. When you use the same keys for commitment transaction watchtower services can basically learn which payments in which amounts go through the channels. And start an attack on the privacy of people making and receiving payments. However if the keys change the channels get obfuscated for the watchtower since the state gets decorolated.

> **Comments:**
> **username_0**: But aren't watchtowers completely blind in this regard? Yeah, they need to get that there was a new commitment immediately. But they don't actually see the stuff itself. You kind of just give them first half of the txid and tell them if you see something like this use the other half to unlock my prepared punishment and send it out. And they will see then if there is something in for them and do it. Or do you somehow need to prove to them that it is worth storing the data beforehand?  
> **username_3**: I don't think that's the case. As @username_0 was commenting the towers are blind in this regard except when there's a channel breach. To my understanding, the main reason behind using different keys is to obfuscate the state in case of a breach, independently of whether there is any tower or not.  
> **username_4**: Might be related: https://bitcoin.stackexchange.com/questions/91437/if-a-user-recovered-data-directory-of-ln-node-software-with-an-old-backup-what/  

---

