What is Nostr?
Tomas [ARCHIVE] /
npub1rsp…evk4
2023-06-09 12:47:39
in reply to nevent1q…m4eg

Tomas [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-13 📝 Original message: Thank you for your ...

📅 Original date posted:2017-11-13
📝 Original message:
Thank you for your feedback,

On Sun, Nov 12, 2017, at 04:04, Rusty Russell wrote:
> Malleation is a problem for every commitment transaction: we use HTLC
> transactions which depend on it. Now, in theory SIGHASH_NOINPUT could
> be used to work around malleation here too, by allowing you to update
> the dependent transaction, but you need separate keys on every output to
> ensure that transactions can't be connected to the wrong outputs.

But doesn't the current specification already ensure that every key is
only used once? At least that is what I am understanding from the key
derivation rules at:

https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md

>
> IIRC it cuts the number of updates down by about a factor of 2 under
> typical use, more under weird conditions. Basically you can re-attach
> the HTLC transaction instead of needing a new one.
>
> IMHO SIGHASH_NOINPUT is a generally nice thing to have, though it's
> extremely dangerous if you reuse keys at all. So, don't do that :)

If the prescribed key derivation algorithm ensures uniqueness, under
what circumstances could the keys be reused? Is it just a faulty
implementation here that is the risk?

Thank you,
Tomas
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4