From tomas at bitcrust.org  Mon Nov 13 09:38:41 2017
From: tomas at bitcrust.org (Tomas)
Date: Mon, 13 Nov 2017 10:38:41 +0100
Subject: [Lightning-dev] Questions on SIGHASH_NOINPUT
In-Reply-To: <87y3ncurhk.fsf@rustcorp.com.au>
References: <1510316855.1013962.1168110080.4FFCD840@webmail.messagingengine.com>
	<87y3ncurhk.fsf@rustcorp.com.au>
Message-ID: <1510565921.2464556.1170513728.61FADCC5@webmail.messagingengine.com>

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