MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210618.56159.luke@dashjr.org>
	<CAAS2fgT4DU1MuOwo0Qr4yMNRamajD=KrOVP93pzApWMpry-Srg@mail.gmail.com>
	<CAAS2fgR7X2j9buFQXvgmWZCfoasRa=nLB5efnu-ZnqFZC+SeuQ@mail.gmail.com>
	<CALxbBHV14BW+S809rX0TuAjB65b90=1bnN6pondQO6qWVPi3+w@mail.gmail.com>
In-Reply-To: <CALxbBHV14BW+S809rX0TuAjB65b90=1bnN6pondQO6qWVPi3+w@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 08:50:45 +0000
Message-ID: <CALxbBHU2si5J7QzsBjicOzw=z2u2eGDBna_APv+cWAMo5DmmJA@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>, Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=f46d04428f24f1aef20522997952
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

--f46d04428f24f1aef20522997952
Content-Type: text/plain; charset=UTF-8

Ok, so the normalization step could add a sorting step for inputs/outputs
(which is going to be nasty for SIGHASH_SINGLE), that would solve the issue.

On Wed, Oct 21, 2015 at 10:49 AM Christian Decker <
decker.christian@gmail.com> wrote:

> On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> 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.
>>
>>
> Isn't that sort of what this BIP describes as well? Except that we use the
> scriptSig to transport the signatures internally to the transactions and
> strip them when it comes to signing/checking? The wire format and transport
> of transactions do not change so old clients continue to fetch and process
> transactions as before, they just can't verify the TX. Blocks still
> reference the instance but verification uses the stripped TX with the
> signatures on the side, etc.
>
>
>> 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.
>>
>

--f46d04428f24f1aef20522997952
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, so the normalization step could add a sorting step for=
 inputs/outputs (which is going to be nasty for SIGHASH_SINGLE), that would=
 solve the issue.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On W=
ed, Oct 21, 2015 at 10:49 AM Christian Decker &lt;<a href=3D"mailto:decker.=
christian@gmail.com">decker.christian@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><di=
v dir=3D"ltr">On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell &lt;<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 21, 2015 at 7:4=
8 AM, Gregory Maxwell &lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_=
blank">gmaxwell@gmail.com</a>&gt; wrote:<br>
&gt; I&#39;m still sad that uniform segregated witeness is so hard to deplo=
y,<br>
&gt; adding another id to every utxo set won&#39;t be a nice cost. :( But I=
<br>
&gt; have been trying for a long time to come up with anything better and<b=
r>
&gt; not being successful.<br>
<br>
Oh good. Luke solved it.<br>
<br>
To deploy SW without a disruptive flag day this encoding could be used:<br>
<br>
A new P2SH like scriptPubkey type is defined. In the soft-fork, the<br>
scriptsig for this scriptPubkey is required to be empty.<br>
<br>
Signatures are not covered under txid, but carried along side. Then<br>
committed to in blocks in a separate hashtree.<br>
<br></blockquote><div><br></div></div></div><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div>Isn&#39;t that sort of what this BIP describes as well? E=
xcept that we use the scriptSig to transport the signatures internally to t=
he transactions and strip them when it comes to signing/checking? The wire =
format and transport of transactions do not change so old clients continue =
to fetch and process transactions as before, they just can&#39;t verify the=
 TX. Blocks still reference the instance but verification uses the stripped=
 TX with the signatures on the side, etc.</div></div></div><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
The only disadvantage to the approach used in elements alpha that I<br>
can come up with so far (in the few minutes since luke turned my can&#39;t<=
br>
into a can) is that that the approach in EA did not disrupt the normal<br>
relay handling process, and this would, since relay that transports<br>
the extradata either needs to use a different hash that includes the<br>
witness, or have a separate mechanism for witness transport.<br>
</blockquote></div></div></blockquote></div>

--f46d04428f24f1aef20522997952--