MIME-Version: 1.0
In-Reply-To: <201510210618.56159.luke@dashjr.org>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210618.56159.luke@dashjr.org>
Date: Wed, 21 Oct 2015 07:48:39 +0000
Message-ID: <CAAS2fgT4DU1MuOwo0Qr4yMNRamajD=KrOVP93pzApWMpry-Srg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

On Wed, Oct 21, 2015 at 6:18 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:
>> The proposal is implemented (see below), by computing the normalized
>> transaction ID when adding them to the UTXO and storing them along with the
>> coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
>> OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
>> how to best refactor the common functionality into reusable blocks. And the
>> annotating incoming transactions with their normalized inputs is a bit
>> cumbersome, maye somebody has some pointers here as well?
>
> This doesn't completely close malleability (which should be documented in the
> BIP), so I'm not sure it's worth the cost, especially if closing malleability
> later on would need more. How about specifying flags upfront in the UTXO-
> creating transaction specifying which parts the signature will cover? This
> would allow implementation of fully malleability-proof wallets.
>
> Additionally, you have a flag to control whether the opcode behaves as VERIFY
> or not. Non-VERIFY is not possible as a softfork (without doing a second/new
> P2SH) since it can be negated.

Flagability cannot work recursively which is necessary for any
improvement to be useful for multi-phase protocols. (which, I think,
is the only real application of this class of improvement-- third
party mutation can be prevented by enforced canonical encodings;)

One still wants sighash flags--, but they're going to inherently
result in malleability.

I'm still sad that uniform segregated witeness is so hard to deploy,
adding another id to every utxo set won't be a nice cost. :( But I
have been trying for a long time to come up with anything better and
not being successful.