1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D7E451BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:50:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
[209.85.212.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DE2DA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:50:56 +0000 (UTC)
Received: by wicfv8 with SMTP id fv8so64258481wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 01:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=jZcAvp6jyrlvDFpgJvbucd0CTYj3e18185UAR9b2ifo=;
b=nctUdj6vMHewKz1mA1vwP7Xkg+VYITFtHUhJA9SofrxKkdHwBddg2Z8+dnCmTEVSHp
RqQsUaGTiHxGMRCJP3/nAPsaLXn0noHeYHoFM8h98f+QI//GubB7zv+AqMSbxKoaTUCm
C+P7/z+fqhCffLt+qJ+OMiRewCojYwKzWO8jZ5kyvEJJD4JZuKv29P9351KtWD4EGMaT
qXE9UnTw3b5S8XBqzYV+J6OBVoPQr801UG0PvVmUOPvc0R/E6gJPJQ7mu9Hm0uvrp6uJ
PPUU6fGud0ekVOGC5e4GPqoYDukoYGvYXho/dgcqE+SJt6R7Nmhe8LgHN+TOk/81XIux
ZZ4A==
X-Received: by 10.180.88.34 with SMTP id bd2mr17243750wib.82.1445417454766;
Wed, 21 Oct 2015 01:50:54 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 08:50:56 -0000
--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 <<a href=3D"mailto:decker.=
christian@gmail.com">decker.christian@gmail.com</a>> 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 <<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>=
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 <<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_=
blank">gmaxwell@gmail.com</a>> wrote:<br>
> I'm still sad that uniform segregated witeness is so hard to deplo=
y,<br>
> adding another id to every utxo set won't be a nice cost. :( But I=
<br>
> have been trying for a long time to come up with anything better and<b=
r>
> 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'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'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'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--
|
