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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WGUJG-0006Gj-90
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 14:09:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.50 as permitted sender)
client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f50.google.com;
Received: from mail-oa0-f50.google.com ([209.85.219.50])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGUJE-00026j-UJ
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 14:09:06 +0000
Received: by mail-oa0-f50.google.com with SMTP id n16so2121244oag.37
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Feb 2014 06:08:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.219.167 with SMTP id pp7mr1535098obc.85.1392905339512;
Thu, 20 Feb 2014 06:08:59 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 06:08:59 -0800 (PST)
Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 06:08:59 -0800 (PST)
In-Reply-To: <81A62AB7-9EC6-439E-96CF-F064F0151BB9@mac.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
<52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org>
<CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
<CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
<EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@mac.com>
<CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
<601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
<CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
<81A62AB7-9EC6-439E-96CF-F064F0151BB9@mac.com>
Date: Thu, 20 Feb 2014 14:08:59 +0000
X-Google-Sender-Auth: HEsQuUBzV_ONhi7-dn93ZXxohtQ
Message-ID: <CANEZrP26U3BjEi66xjD9SRxrAupGmYC6mKiYYw27BH3q1b1hLQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@mac.com>
Content-Type: multipart/alternative; boundary=089e0141ab82f7add504f2d70b84
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WGUJE-00026j-UJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
malleability
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: Thu, 20 Feb 2014 14:09:06 -0000
--089e0141ab82f7add504f2d70b84
Content-Type: text/plain; charset=UTF-8
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
On 20 Feb 2014 16:30, "Michael Gronager" <gronager@mac.com> wrote:
> As I see the BIP it is basically stressing that ver 1 transactions are
> malleable.
>
> It then addresses the need for unmalleable transactions for e.g. spending
> unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage)
> - this transaction type is defined as ver 3.
>
> A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as
> such make an implicit assumption that this is kind of safe, which it is not
> - it can be intervened and sabotaged through tx malleability.
>
> What I suggested was to ensure that a subclass of version 1 transactions
> become unmalleable - namely those with sighash=all. Note that only the
> sender can modify the sighash as it is part of the hash signed. So instead
> of defining a version 3, we could constrain version 1 txes with sighash=all
> to have a unmalleable hash. If you e.g. would like to still have a
> sighash=all type of transaction with malleable features you can simply use
> that sighash=all today is checked for using sighash&0x1f=sighash_all, so
> just OR'ing with 0x20 or 0x40 will get you the 'old' feature.
>
> I do however buy the argument of Peter and Gregory that there might exist
> unpublished transactions out there that does not even conform to the DER
> rules etc, and as such we cannot forbid them from being mined, nor can we
> timestamp them and include 'only the old ones'. Hence we cannot change the
> consensus rule for version 1 transactions - and only changing the relay
> rules will not provide a certain guarantee.
>
> So, I think the two line argument for the BIP is as follows:
> 1. We cannot change the consensus rules for version 1 transactions as that
> might invalidate unpublished non-standard transactions (= voiding peoples
> money, which is a line we don't want to cross)
> 2. The prime usecase for unmalleable transactions is being able to spend
> unconfirmed outputs - this is done today by almost all clients, but it is
> really broken. Hence a need for a fix asap.
>
> I am all in favor for the BIP, but I expect the realistic timeline for
> enforced version 3 transactions is roughly one year, which is better than
> two, but it would have been nice to get it faster...
>
> /M
>
>
> On Feb 19, 2014, at 10:11 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
> > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager@mac.com>
> wrote:
> >> I think that we could guarantee fewer incidents by making version 1
> transactions unmalleable and then optionally introduce a version 3 that
> supported the malleability feature. That way most existing problematic
> implementations would be fixed and no doors were closed for people
> experimenting with other stuff - tx v 3 would probably then be called
> experimental transactions.
> >
> > Just to be clear: this change is not directly intended to avoid
> > "incidents". It will take way too long to deploy this. Software should
> > deal with malleability. This is a longer-term solution intended to
> > provide non-malleability guarantees for clients that a) are upgraded
> > to use them b) willing to restrict their functionality. As there are
> > several intended use cases for malleable transactions (the sighash
> > flags pretty directly are a way to signify what malleabilities are
> > *wanted*), this is not about outlawing malleability.
> >
> > While we could right now make all these rules non-standard, and
> > schedule a soft fork in a year or so to make them illegal, it would
> > mean removing potential functionality that can only be re-enabled
> > through a hard fork. This is significantly harder, so we should think
> > about it very well in advance.
> >
> > About new transaction and block versions: this allows implementing and
> > automatically scheduling a softfork without waiting for wallets to
> > upgrade. The non-DER signature change was discussed for over two
> > years, and implemented almost a year ago, and we still notice wallets
> > that don't support it. We can't expect every wallet to be instantly
> > modified (what about hardware wallets like the Trezor, for example?
> > they may not just be able to be upgraded). Nor is it necessary: if
> > your software only spends confirmed change, and tracks all debits
> > correctly, there is no need.
> >
> > --
> > Pieter
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e0141ab82f7add504f2d70b84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">We've done forking changes before much faster than a yea=
r and that was with less experience. If we want, we can get this done withi=
n months.</p>
<div class=3D"gmail_quote">On 20 Feb 2014 16:30, "Michael Gronager&quo=
t; <<a href=3D"mailto:gronager@mac.com">gronager@mac.com</a>> wrote:<=
br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I see the BIP it is basically stressing that ver 1 transactions are mall=
eable.<br>
<br>
It then addresses the need for unmalleable transactions for e.g. spending u=
nconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) =
- this transaction type is defined as ver 3.<br>
<br>
A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as s=
uch make an implicit assumption that this is kind of safe, which it is not =
- it can be intervened and sabotaged through tx malleability.<br>
<br>
What I suggested was to ensure that a subclass of version 1 transactions be=
come unmalleable - namely those with sighash=3Dall. Note that only the send=
er can modify the sighash as it is part of the hash signed. So instead of d=
efining a version 3, we could constrain version 1 txes with sighash=3Dall t=
o have a unmalleable hash. If you e.g. would like to still have a sighash=
=3Dall type of transaction with malleable features you can simply use that =
sighash=3Dall today is checked for using sighash&0x1f=3Dsighash_all, so=
just OR'ing with 0x20 or 0x40 will get you the 'old' feature.<=
br>
<br>
I do however buy the argument of Peter and Gregory that there might exist u=
npublished transactions out there that does not even conform to the DER rul=
es etc, and as such we cannot forbid them from being mined, nor can we time=
stamp them and include 'only the old ones'. Hence we cannot change =
the consensus rule for version 1 transactions - and only changing the relay=
rules will not provide a certain guarantee.<br>
<br>
So, I think the two line argument for the BIP is as follows:<br>
1. We cannot change the consensus rules for version 1 transactions as that =
might invalidate unpublished non-standard transactions (=3D voiding peoples=
money, which is a line we don't want to cross)<br>
2. The prime usecase for unmalleable transactions is being able to spend un=
confirmed outputs - this is done today by almost all clients, but it is rea=
lly broken. Hence a need for a fix asap.<br>
<br>
I am all in favor for the BIP, but I expect the realistic timeline for enfo=
rced version 3 transactions is roughly one year, which is better than two, =
but it would have been nice to get it faster...<br>
<br>
/M<br>
<br>
<br>
On Feb 19, 2014, at 10:11 PM, Pieter Wuille <<a href=3D"mailto:pieter.wu=
ille@gmail.com">pieter.wuille@gmail.com</a>> wrote:<br>
<br>
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <<a href=3D"mailt=
o:gronager@mac.com">gronager@mac.com</a>> wrote:<br>
>> I think that we could guarantee fewer incidents by making version =
1 transactions unmalleable and then optionally introduce a version 3 that s=
upported the malleability feature. That way most existing problematic imple=
mentations would be fixed and no doors were closed for people experimenting=
with other stuff - tx v 3 would probably then be called experimental trans=
actions.<br>
><br>
> Just to be clear: this change is not directly intended to avoid<br>
> "incidents". It will take way too long to deploy this. Softw=
are should<br>
> deal with malleability. This is a longer-term solution intended to<br>
> provide non-malleability guarantees for clients that a) are upgraded<b=
r>
> to use them =C2=A0b) willing to restrict their functionality. As there=
are<br>
> several intended use cases for malleable transactions (the sighash<br>
> flags pretty directly are a way to signify what malleabilities are<br>
> *wanted*), this is not about outlawing malleability.<br>
><br>
> While we could right now make all these rules non-standard, and<br>
> schedule a soft fork in a year or so to make them illegal, it would<br=
>
> mean removing potential functionality that can only be re-enabled<br>
> through a hard fork. This is significantly harder, so we should think<=
br>
> about it very well in advance.<br>
><br>
> About new transaction and block versions: this allows implementing and=
<br>
> automatically scheduling a softfork without waiting for wallets to<br>
> upgrade. The non-DER signature change was discussed for over two<br>
> years, and implemented almost a year ago, and we still notice wallets<=
br>
> that don't support it. We can't expect every wallet to be inst=
antly<br>
> modified (what about hardware wallets like the Trezor, for example?<br=
>
> they may not just be able to be upgraded). Nor is it necessary: if<br>
> your software only spends confirmed change, and tracks all debits<br>
> correctly, there is no need.<br>
><br>
> --<br>
> Pieter<br>
<br>
<br>-----------------------------------------------------------------------=
-------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk</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>
--089e0141ab82f7add504f2d70b84--
|
