2

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?

Improve this question
1
  • 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
    Commented Dec 6, 2019 at 22:20

2 Answers 2

Reset to default
1

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.

Improve this answer
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.

Improve this answer
3
  • 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
    Commented Dec 6, 2019 at 23:42
  • 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
    Commented Dec 10, 2019 at 9:14
  • Might be related: bitcoin.stackexchange.com/questions/91437/…
    – Chris Chen
    Commented Dec 11, 2019 at 6:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.