Lightning - why are commitment transactions supposed to use different keys 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?
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, 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.