From: Luke Dashjr <luke@dashjr.org>
To: Christian Decker <decker.christian@gmail.com>
Date: Tue, 3 Nov 2015 20:48:17 +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>
	<201510220905.27124.luke@dashjr.org>
	<CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
In-Reply-To: <CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201511032048.18680.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:
> I am still very much intrigued by Luke's idea of having empty scriptsigs
> and ship the signatures in external scripts, however the proposal uses the
> on-the-fly normalization because we have no good way of relaying the
> external scripts. Since we are still in the drafting phase I am open to
> suggestions and if there is a good/working solution I can amend/withdraw
> the proposal.

Changing the network protocol is trivial in comparison to making a permanent 
increase in UTXO set costs.

> As for open venues for malleability, I'm not sure we can fix them at all,
> after all the ability of a single signer to doublespend by
> appending/replacing inputs/outputs in an arbitrary fashion is not fixable
> IMHO and will cause any future transaction building on its outputs to be
> orphaned. What would the perfect properties for such a fix be?

The problem isn't changing inputs/outputs, but that such changes invalidate 
later spends. In particular, note that wallets *should ideally* be actively 
trying to make transfers using multiple malleated versions of the same 
payment.

So the way to make an anti-malleable wallet, would be to strictly enforce the 
no-address-reuse rule on payments received (note this has no effect on 
other/current wallets) and rely only on the hash of that scriptPubKey+value 
for the input in subsequent transactions. This way, no matter what inputs or 
other outputs the transaction paying the address/invoice uses, the subsequent 
transaction ignores them and remains valid. (I am not suggesting this as a 
mandatory change that all wallets must adopt to receive the current semi-
malleability protection you propose - only that it be *possible* for wallets 
to upgrade to or offer in the future.)

Luke