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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1YsaEX-0005RZ-Vl
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 17:14:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.48 as permitted sender)
client-ip=209.85.218.48; envelope-from=pieter.wuille@gmail.com;
helo=mail-oi0-f48.google.com;
Received: from mail-oi0-f48.google.com ([209.85.218.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsaEW-0001gH-JH
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 17:14:13 +0000
Received: by oift201 with SMTP id t201so36541926oif.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 10:14:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.177.86 with SMTP id a83mr16015476oif.14.1431537247174;
Wed, 13 May 2015 10:14:07 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 10:14:07 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 10:14:07 -0700 (PDT)
In-Reply-To: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
Date: Wed, 13 May 2015 10:14:07 -0700
Message-ID: <CAPg+sBggj382me1ATDx4SS9KHVfvX5KH7ZhLHN6B+2_a+Emw1Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary=001a113cd2ac19c8b00515f9bdb7
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YsaEW-0001gH-JH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2015 17:14:14 -0000
--001a113cd2ac19c8b00515f9bdb7
Content-Type: text/plain; charset=ISO-8859-1
Normalized transaction ids are only effectively non-malleable when all
inputs they refer to are also non-malleable (or you can have malleability
in 2nd level dependencies), so I do not believe it makes sense to allow
mixed usage of the txids at all. They do not provide the actual benefit of
guaranteed non-malleability before it becomes disallowed to use the old
mechanism. That, together with the +- resource doubling needed for the UTXO
set (as earlier mentioned) and the fact that an alternative which is only a
softfork are available, makes this a bad idea IMHO.
Unsure to what extent this has been presented on the mailinglist, but the
softfork idea is this:
* Transactions get 2 txids, one used to reference them (computed as
before), and one used in an (extended) sighash.
* The txins keep using the normal txid, so not structural changes to
Bitcoin.
* The ntxid is computed by replacing the scriptSigs in inputs by the empty
string, and by replacing the txids in txins by their corresponding ntxids.
* A new checksig operator is softforked in, which uses the ntxids in its
sighashes rather than the full txid.
* To support efficiently computing ntxids, every tx in the utxo set
(currently around 6M) stores the ntxid, but only supports lookup bu txid
still.
This does result in a system where a changed dependency indeed invalidates
the spending transaction, but the fix is trivial and can be done without
access to the private key.
On May 13, 2015 5:50 AM, "Christian Decker" <decker.christian@gmail.com>
wrote:
> Hi All,
>
> I'd like to propose a BIP to normalize transaction IDs in order to address
> transaction malleability and facilitate higher level protocols.
>
> The normalized transaction ID is an alias used in parallel to the current
> (legacy) transaction IDs to address outputs in transactions. It is
> calculated by removing (zeroing) the scriptSig before computing the hash,
> which ensures that only data whose integrity is also guaranteed by the
> signatures influences the hash. Thus if anything causes the normalized ID
> to change it automatically invalidates the signature. When validating a
> client supporting this BIP would use both the normalized tx ID as well as
> the legacy tx ID when validating transactions.
>
> The detailed writeup can be found here:
> https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>
> @gmaxwell: I'd like to request a BIP number, unless there is something
> really wrong with the proposal.
>
> In addition to being a simple alternative that solves transaction
> malleability it also hugely simplifies higher level protocols. We can now
> use template transactions upon which sequences of transactions can be built
> before signing them.
>
> I hesitated quite a while to propose it since it does require a hardfork
> (old clients would not find the prevTx identified by the normalized
> transaction ID and deem the spending transaction invalid), but it seems
> that hardforks are no longer the dreaded boogeyman nobody talks about.
> I left out the details of how the hardfork is to be done, as it does not
> really matter and we may have a good mechanism to apply a bunch of
> hardforks concurrently in the future.
>
> I'm sure it'll take time to implement and upgrade, but I think it would be
> a nice addition to the functionality and would solve a long standing
> problem :-)
>
> Please let me know what you think, the proposal is definitely not set in
> stone at this point and I'm sure we can improve it further.
>
> Regards,
> Christian
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a113cd2ac19c8b00515f9bdb7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Normalized transaction ids are only effectively non-malleabl=
e when all inputs they refer to are also non-malleable (or you can have mal=
leability in 2nd level dependencies), so I do not believe it makes sense to=
allow mixed usage of the txids at all. They do not provide the actual bene=
fit of guaranteed non-malleability before it becomes disallowed to use the =
old mechanism. That, together with the +- resource doubling needed for the =
UTXO set (as earlier mentioned) and the fact that an alternative which is o=
nly a softfork are available, makes this a bad idea IMHO.</p>
<p dir=3D"ltr">Unsure to what extent this has been presented on the mailing=
list, but the softfork idea is this:<br>
* Transactions get 2 txids, one used to reference them (computed as before)=
, and one used in an (extended) sighash.<br>
* The txins keep using the normal txid, so not structural changes to Bitcoi=
n.<br>
* The ntxid is computed by replacing the scriptSigs in inputs by the empty =
string, and by replacing the txids in txins by their corresponding ntxids.<=
br>
* A new checksig operator is softforked in, which uses the ntxids in its si=
ghashes rather than the full txid.<br>
* To support efficiently computing ntxids, every tx in the utxo set (curren=
tly around 6M) stores the ntxid, but only supports lookup bu txid still.</p=
>
<p dir=3D"ltr">This does result in a system where a changed dependency inde=
ed invalidates the spending transaction, but the fix is trivial and can be =
done without access to the private key.</p>
<div class=3D"gmail_quote">On May 13, 2015 5:50 AM, "Christian Decker&=
quot; <<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gm=
ail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Hi All,</div><div><br></div>I'd like to propos=
e a BIP to normalize transaction IDs in order to address transaction mallea=
bility and facilitate higher level protocols.<div><br></div><div>The normal=
ized transaction ID is an alias used in parallel to the current (legacy) tr=
ansaction IDs to address outputs in transactions. It is calculated by remov=
ing (zeroing) the scriptSig before computing the hash, which ensures that o=
nly data whose integrity is also guaranteed by the signatures influences th=
e hash. Thus if anything causes the normalized ID to change it automaticall=
y invalidates the signature. When validating a client supporting this BIP w=
ould use both the normalized tx ID as well as the legacy tx ID when validat=
ing transactions.</div><div><br></div><div>The detailed writeup can be foun=
d here:=A0<a href=3D"https://github.com/cdecker/bips/blob/normalized-txid/b=
ip-00nn.mediawiki" target=3D"_blank">https://github.com/cdecker/bips/blob/n=
ormalized-txid/bip-00nn.mediawiki</a>.</div><div><br></div><div>@gmaxwell: =
I'd like to request a BIP number, unless there is something really wron=
g with the proposal.</div><div><br></div><div>In addition to being a simple=
alternative that solves transaction malleability it also hugely simplifies=
higher level protocols. We can now use template transactions upon which se=
quences of transactions can be built before signing them.</div><div><br></d=
iv><div>I hesitated quite a while to propose it since it does require a har=
dfork (old clients would not find the prevTx identified by the normalized t=
ransaction ID and deem the spending transaction invalid), but it seems that=
hardforks are no longer the dreaded boogeyman nobody talks about.</div><di=
v>I left out the details of how the hardfork is to be done, as it does not =
really matter and we may have a good mechanism to apply a bunch of hardfork=
s concurrently in the future.</div><div><br></div><div>I'm sure it'=
ll take time to implement and upgrade, but I think it would be a nice addit=
ion to the functionality and would solve a long standing problem :-)</div><=
div><br></div><div>Please let me know what you think, the proposal is defin=
itely not set in stone at this point and I'm sure we can improve it fur=
ther.</div><div><br></div><div>Regards,</div><div>Christian</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>
--001a113cd2ac19c8b00515f9bdb7--
|
