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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
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 CD588305
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Oct 2015 10:30:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
[209.85.212.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB662A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Oct 2015 10:30:45 +0000 (UTC)
Received: by wijp11 with SMTP id p11so40155987wij.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Oct 2015 03:30:44 -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
:content-type; bh=f5gC7tXZB2/KLQd83cH47e1izBJa9QHCI2/l0n6ZbQk=;
b=bQSwtQwKnA62eMkQjio1DophY4ObKCNzFfatxARcVrI1gyv097C0m/h1KT4mprONbW
r4VRLd5Tjqvpgmu+2erdwFd5wolEINVv9uJySjdz06sO5w2otv8m+uS6P+JA11NTJ1/k
kiVqWOC+/CZA+MR2WpD8YcMcKI74XHGbufymD7NkhASOpLru9m0sXeVY2TOUbx71MbVM
HICpaJmiYNAo0mGZevGEa5I5NRpvObbRqgM1W4u9/IcOd5Iu8NoLV8UAzbHVhb4szIAs
KJLSocjynPXIq/nh8UMtPOWvIGdcdx3MgUSEGEKXddGZVSxVhuIGf9t5X3dJ4asHVfxG
KIDQ==
X-Received: by 10.194.239.230 with SMTP id vv6mr3180334wjc.21.1445337044104;
Tue, 20 Oct 2015 03:30:44 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<CAE-z3OUrM=0XsdfdU2d9h6uhCh9vP83X-OZR8NyAYsvYuE1vtg@mail.gmail.com>
<56256D36.5050801@sky-ip.org>
In-Reply-To: <56256D36.5050801@sky-ip.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 20 Oct 2015 10:30:33 +0000
Message-ID: <CALxbBHVcorvyQnwkDw6O-s6_4uozOY2BB3Aj12H9re2xfyaomA@mail.gmail.com>
To: s7r@sky-ip.org, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0141a3d6183c77052286c13b
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
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: Tue, 20 Oct 2015 10:30:46 -0000
--089e0141a3d6183c77052286c13b
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So what exactly is used to create the normalized txid (sha256 hash of
> what data)? I've read in the linked BIP draft that it will strip the
> 'malleable parts' but didn't understand what exactly will be used to
> calculate the normalized transactions ids and how will the change apply
> retro-active for the transactions so deep buried in the blockchain?
>
The normalization involves two steps:
- strip the scriptSig scripts in the inputs, i.e., the only part whose
integrity is not guaranteed by the signature itself, by replacing the
scripts with empty strings (var length string of size 0)
- replace the hashes referencing the outputs being spent with the
normalized hashes of the transaction that created the outputs. This is done
recursively down to the first v2 transactions.
The second part is not yet explained in the draft, but I will amend it as
soon as possible.
> Pubkeys (addresses) can be reused infinitely so what guarantees us
> unique normalized txids all the time and protection against replay
> attacks? The question is not if this issue is covered or not, I know it
> is, I am just asking how, in simpler terms.
>
Non-coinbase transactions can still not be replayed since the normalized
transaction still includes a the normalized transaction hashes of claimed
outputs, hence any attempt to replay a transaction would fail since the
outputs were already spent. For coinbase transactions it is indeed possible
that we create multiple transactions with the same hash (only one of which
would be spendable), hence we do not strip coinbase transactions and rely
on BIP 34 to make the coinbase transactions unique (except for blocks 91842
and 91880 which are the reason we introduced BIP 34 in the first place).
Clarifying the way the normalized transaction ID is computed should remove
any ambiguities I hope.
>
> SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.
>
> Will it also fix > third level malleability (a tx which spends from
> another unconfirmed tx which spends from yet another unconfirmed tx)?
>
Yes, if the computation of the normalized transaction ID includes replacing
input hashes with their normalized counterpart makes a chain of any depth
non-malleable.
HTH,
Christian
>
>
> On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote:
> > On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > As with the previous version, which was using a hard-fork, the
> > normalized transaction ID is computed only considering the
> > non-malleable parts of a transaction, i.e., stripping the signatures
> > before computing the hash of the transaction.
> > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
> >
> > Is this proposal recursive?
> >
> > *Coinbase transaction
> > *
> >
> > * n-txid = txid
> >
> > *Non-coinbase transactions
> > *
> > * replace sigScripts with empty strings
> > * replace txids in TxIns with n-txid for parents
> >
> > The 2nd step is recursive starting from the coinbases.
> >
> > In effect, the rule is that txids are what they would have been if
> > n-txids had been used right from the start.
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e0141a3d6183c77052286c13b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 20=
, 2015 at 12:23 AM s7r via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">So what exactly is used to creat=
e the normalized txid (sha256 hash of<br>
what data)? I've read in the linked BIP draft that it will strip the<br=
>
'malleable parts' but didn't understand what exactly will be us=
ed to<br>
calculate the normalized transactions ids and how will the change apply<br>
retro-active for the transactions so deep buried in the blockchain?<br></bl=
ockquote><div><br></div><div>The normalization involves two steps:</div><di=
v>=C2=A0- strip the scriptSig scripts in the inputs, i.e., the only part wh=
ose integrity is not guaranteed by the signature itself, by replacing the s=
cripts with empty strings (var length string of size 0)</div><div>=C2=A0- r=
eplace the hashes referencing the outputs being spent with the normalized h=
ashes of the transaction that created the outputs. This is done recursively=
down to the first v2 transactions.</div><div><br></div><div>The second par=
t is not yet explained in the draft, but I will amend it as soon as possibl=
e.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Pubkeys (addresses) can be reused infinitely so what guarantees us<br>
unique normalized txids all the time and protection against replay<br>
attacks? The question is not if this issue is covered or not, I know it<br>
is, I am just asking how, in simpler terms.<br></blockquote><div><br></div>=
<div>Non-coinbase transactions can still not be replayed since the normaliz=
ed transaction still includes a the normalized transaction hashes of claime=
d outputs, hence any attempt to replay a transaction would fail since the o=
utputs were already spent. For coinbase transactions it is indeed possible =
that we create multiple transactions with the same hash (only one of which =
would be spendable), hence we do not strip coinbase transactions and rely o=
n BIP 34 to make the coinbase transactions unique (except for blocks 91842 =
and 91880 which are the reason we introduced BIP 34 in the first place). Cl=
arifying the way the normalized transaction ID is computed should remove an=
y ambiguities I hope.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.<br>
<br>
Will it also fix > third level malleability (a tx which spends from<br>
another unconfirmed tx which spends from yet another unconfirmed tx)?<br></=
blockquote><div><br></div><div>Yes, if the computation of the normalized tr=
ansaction ID includes replacing input hashes with their normalized counterp=
art makes a chain of any depth non-malleable.</div><div><br></div><div>HTH,=
</div><div>Christian=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote:<br>
> On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>>> wrote:<br=
>
><br>
>=C2=A0 =C2=A0 =C2=A0As with the previous version, which was using a har=
d-fork, the<br>
>=C2=A0 =C2=A0 =C2=A0normalized transaction ID is computed only consider=
ing the<br>
>=C2=A0 =C2=A0 =C2=A0non-malleable parts of a transaction, i.e., strippi=
ng the signatures<br>
>=C2=A0 =C2=A0 =C2=A0before computing the hash of the transaction.<br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>><br>
><br>
><br>
> Is this proposal recursive?<br>
><br>
> *Coinbase transaction<br>
> *<br>
><br>
> * n-txid =3D txid<br>
><br>
> *Non-coinbase transactions<br>
> *<br>
> * replace sigScripts with empty strings<br>
> * replace txids in TxIns with n-txid for parents<br>
><br>
> The 2nd step is recursive starting from the coinbases.<br>
><br>
> In effect, the rule is that txids are what they would have been if<br>
> n-txids had been used right from the start.<br>
><br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--089e0141a3d6183c77052286c13b--
|
