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
📝 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