MIME-Version: 1.0
In-Reply-To: <CAAS2fgT4DU1MuOwo0Qr4yMNRamajD=KrOVP93pzApWMpry-Srg@mail.gmail.com>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210618.56159.luke@dashjr.org>
	<CAAS2fgT4DU1MuOwo0Qr4yMNRamajD=KrOVP93pzApWMpry-Srg@mail.gmail.com>
Date: Wed, 21 Oct 2015 08:26:47 +0000
Message-ID: <CAAS2fgR7X2j9buFQXvgmWZCfoasRa=nLB5efnu-ZnqFZC+SeuQ@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 7:48 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 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.

Oh good. Luke solved it.

To deploy SW without a disruptive flag day this encoding could be used:

A new P2SH like scriptPubkey type is defined. In the soft-fork, the
scriptsig for this scriptPubkey is required to be empty.

Signatures are not covered under txid, but carried along side. Then
committed to in blocks in a separate hashtree.

The only disadvantage to the approach used in elements alpha that I
can come up with so far (in the few minutes since luke turned my can't
into a can) is that that the approach in EA did not disrupt the normal
relay handling process, and this would, since relay that transports
the extradata either needs to use a different hash that includes the
witness, or have a separate mechanism for witness transport.