From: Luke Dashjr <luke@dashjr.org>
To: Christian Decker <decker.christian@gmail.com>
Date: Thu, 22 Oct 2015 09:05:26 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510212320.31052.luke@dashjr.org>
	<CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
In-Reply-To: <CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201510220905.27124.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> I think the scenario of the single signer re-ordering the outputs and
> inputs and then re-signing the transaction is in the same category of
> simple double-spends. The signer could just as well sign a completely
> different transaction spending the same coins to somewhere else, so I don't
> think there is a lot we can do about it even if we instate a canonical
> ordering. Even if we order the inputs and outputs the signer can just add a
> new input and output and we would have a different transaction.
> 
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in the
> multi-signer scenario.

Except that unlike malicious double spending, adding more outputs to 
unconfirmed transactions is what wallets *should ideally be doing every time 
they send another transaction*. Spending unconfirmed change is the wrong 
approach. So half-fixing malleability as this PR would, encourages 
inefficient behaviour in multiple ways (first, by not making it malleability-
safe; second, by encouraging spending unconfirmed change).

Luke