Tomas <to...@bitcrust.org> writes: > 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
It's different for different commitment transactions, not not for different HTLC outputs attached to the same transaction. >> 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? Yes, if you reuse addresses, a signed SIGHASH_NOINPUT input can be attached to either one. This may (or may not) be a problem, depending on the exact usage. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
