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
|
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 <gavinandresen@gmail.com>) id 1WGVjt-0002k1-MZ
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 15:40:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=gavinandresen@gmail.com;
helo=mail-yh0-f47.google.com;
Received: from mail-yh0-f47.google.com ([209.85.213.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGVjs-0005SG-La
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 15:40:41 +0000
Received: by mail-yh0-f47.google.com with SMTP id c41so814973yho.20
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Feb 2014 07:40:35 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.236.120.147 with SMTP id p19mr4282147yhh.6.1392910834616;
Thu, 20 Feb 2014 07:40:34 -0800 (PST)
Received: by 10.170.133.213 with HTTP; Thu, 20 Feb 2014 07:40:34 -0800 (PST)
Date: Thu, 20 Feb 2014 10:40:34 -0500
Message-ID: <CABsx9T3+TOQ6c7=qEhOoc+tYSp=jba-o8MA3Z8N9t05BDdYS5w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=20cf3010e48d8050eb04f2d853bd
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
(gavinandresen[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: 1WGVjs-0005SG-La
Subject: [Bitcoin-development] Transaction malleability in the core code:
update
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 15:40:41 -0000
--20cf3010e48d8050eb04f2d853bd
Content-Type: text/plain; charset=ISO-8859-1
A quick update on the state of transaction malleability work in
Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term
malleability issues, just the very short-term work being done (or already
done) to the reference implementation.
First, the problems:
We've had a longstanding TODO to improve the way the core code deals with
double-spends. From the core code's point of view, malleable transactions
are just one particular form of double-spend.
Improving double-spend handling never made it to the top of the TODO list,
because the cases where it happened involved doing unsupported things (like
copying your wallet.dat to another machine and then spending on both
machines).
And because there is a heavy-handed workaround if a wallet becomes confused
because of a double-spend: restore all of the keys, rescan for
transactions confirmed in the blockchain, and any outputs tied up in
double-spends get released. Coins (really, unspent transaction outputs)
were never permanently lost, but they could be tied up and unspendable when
associated with a 0-confirmation transaction that would never confirm.
So, work in progress or done:
https://github.com/bitcoin/bitcoin/pull/3659
https://github.com/bitcoin/bitcoin/pull/3674
These implements a kinder, gentler sledgehammer (-zapwallettxes) to fix a
confused wallet. If you have a wallet with 0-confirmation transactions that
are tying up bitcoins these should fix it.
https://github.com/bitcoin/bitcoin/pull/3651
https://github.com/bitcoin/bitcoin/pull/3657
https://github.com/bitcoin/bitcoin/pull/3676
These three merged pull requests implement a new command-line option:
-nospendzeroconfchange . The best way to get a wallet confused is to spend
zero-confirmation change outputs that you created yourself; if the
transaction creating the change gets mutated, then the subsequent
transaction is invalid and will never confirm.
The core code spends unconfirmed change only as a last resort. If you are a
service using bitcoind that generates a lot of transactions then best
practice would be to run with -nospendzeroconfchange, and use "sendmany" to
batch payments only after previous payments have confirmed.
https://github.com/bitcoin/bitcoin/pull/3025
This tightens up the IsStandard() rule, so the easiest-to-implement method
of mutating transactions is blocked. Many big mining pools are already
running this patch.
https://github.com/bitcoin/bitcoin/pull/3669
https://github.com/bitcoin/bitcoin/pull/3671
https://github.com/bitcoin/bitcoin/pull/3694
These three get at the root of the problem; they rework the core wallet
code to implement "handle double spends better." See the pull requests for
details.
How can you help:
Testing and code review is, as always, the bottleneck for getting out a
release with these changes.
We have a chronic problem with people running Bitcoin services on top of
the core code waiting until there is an "official" release, and then
assuming that somebody else has done the hard work of reviewing and testing
the changes.
YOU SHOULD NOT BE MAKING THAT ASSUMPTION! Your particular RPC call usage
might trigger some edge-case bug that was missed, or perhaps the size of
your wallet triggers a performance problem introduced by a fix.
Or, in other words: do not treat the core development team as if we were a
commercial company that sold you a software library. That is not how open
source works; if you are making a profit using the software, you are
expected to help develop, debug, test, and review it.
--
--
Gavin Andresen
--20cf3010e48d8050eb04f2d853bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A quick update on the state of transaction malleability wo=
rk in Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term=
malleability issues, just the very short-term work being done (or already =
done) to the reference implementation.<div>
<br></div><div>First, the problems:</div><div><br></div><div>We've had =
a longstanding TODO to improve the way the core code deals with double-spen=
ds. From the core code's point of view, malleable transactions are just=
one particular form of double-spend.</div>
<div><br></div><div>Improving double-spend handling never made it to the to=
p of the TODO list, because the cases where it happened involved doing unsu=
pported things (like copying your wallet.dat to another machine and then sp=
ending on both machines).</div>
<div><br></div><div>And because there is a heavy-handed workaround if a wal=
let becomes confused because of a double-spend: =A0restore all of the keys,=
rescan for transactions confirmed in the blockchain, and any outputs tied =
up in double-spends get released. Coins (really, unspent transaction output=
s) were never permanently lost, but they could be tied up and unspendable w=
hen associated with a 0-confirmation transaction that would never confirm.<=
/div>
<div><br></div><div>So, work in progress or done:</div><div><br></div><div>=
<div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3659">https://githu=
b.com/bitcoin/bitcoin/pull/3659</a></div><div><a href=3D"https://github.com=
/bitcoin/bitcoin/pull/3674">https://github.com/bitcoin/bitcoin/pull/3674</a=
></div>
<div><br></div><div>These implements a kinder, gentler sledgehammer (-zapwa=
llettxes) to fix a confused wallet. If you have a wallet with 0-confirmatio=
n transactions that are tying up bitcoins these should fix it.<br><div>
</div></div></div><div><br></div><div><br></div><div><a href=3D"https://git=
hub.com/bitcoin/bitcoin/pull/3651">https://github.com/bitcoin/bitcoin/pull/=
3651</a><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3=
657">https://github.com/bitcoin/bitcoin/pull/3657</a><br>
</div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3676">https:/=
/github.com/bitcoin/bitcoin/pull/3676</a><br></div><div><br></div><div>Thes=
e three merged pull requests implement a new command-line option: -nospendz=
eroconfchange . =A0The best way to get a wallet confused is to spend zero-c=
onfirmation change outputs that you created yourself; if the transaction cr=
eating the change gets mutated, then the subsequent transaction is invalid =
and will never confirm.</div>
<div><br></div><div>The core code spends unconfirmed change only as a last =
resort. If you are a service using bitcoind that generates a lot of transac=
tions then best practice would be to run with -nospendzeroconfchange, and u=
se "sendmany" to batch payments only after previous payments have=
confirmed.</div>
<div><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3025=
">https://github.com/bitcoin/bitcoin/pull/3025</a><br></div><div><br></div>=
<div>This tightens up the IsStandard() rule, so the easiest-to-implement me=
thod of mutating transactions is blocked. Many big mining pools are already=
running this patch.</div>
<div><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3669=
">https://github.com/bitcoin/bitcoin/pull/3669</a><br></div><div><a href=3D=
"https://github.com/bitcoin/bitcoin/pull/3671">https://github.com/bitcoin/b=
itcoin/pull/3671</a><br>
</div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3694">https:/=
/github.com/bitcoin/bitcoin/pull/3694</a><br></div><div><br></div><div>Thes=
e three get at the root of the problem; they rework the core wallet code to=
implement "handle double spends better." =A0See the pull request=
s for details.</div>
<div><br></div><div>How can you help:</div><div><br></div><div>Testing and =
code review is, as always, the bottleneck for getting out a release with th=
ese changes.</div><div><br></div><div>We have a chronic problem with people=
running Bitcoin services on top of the core code waiting until there is an=
"official" release, and then assuming that somebody else has don=
e the hard work of reviewing and testing the changes.</div>
<div><br></div><div>YOU SHOULD NOT BE MAKING THAT ASSUMPTION! =A0Your parti=
cular RPC call usage might trigger some edge-case bug that was missed, or p=
erhaps the size of your wallet triggers a performance problem introduced by=
a fix.</div>
<div><br></div><div>Or, in other words: do not treat the core development t=
eam as if we were a commercial company that sold you a software library. Th=
at is not how open source works; if you are making a profit using the softw=
are, you are expected to help develop, debug, test, and review it.</div>
<div><br></div><div><div>-- <br>--<br>Gavin Andresen<br>
</div></div><div><br></div></div>
--20cf3010e48d8050eb04f2d853bd--
|
