From rusty at rustcorp.com.au Wed Nov 15 10:37:22 2017 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 15 Nov 2017 21:07:22 +1030 Subject: [Lightning-dev] Questions on SIGHASH_NOINPUT In-Reply-To: <1510565921.2464556.1170513728.61FADCC5@webmail.messagingengine.com> References: <1510316855.1013962.1168110080.4FFCD840@webmail.messagingengine.com> <87y3ncurhk.fsf@rustcorp.com.au> <1510565921.2464556.1170513728.61FADCC5@webmail.messagingengine.com> Message-ID: <87shdf4yl9.fsf@rustcorp.com.au> Tomas 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.