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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1S2QEN-0001O1-Lr
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 16:48:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=pieter.wuille@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S2QEM-0004Ov-M5
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 16:48:51 +0000
Received: by wibhq12 with SMTP id hq12so1413338wib.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Feb 2012 08:48:44 -0800 (PST)
Received-SPF: pass (google.com: domain of pieter.wuille@gmail.com designates
10.180.107.68 as permitted sender) client-ip=10.180.107.68;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
pieter.wuille@gmail.com designates 10.180.107.68 as permitted
sender) smtp.mail=pieter.wuille@gmail.com;
dkim=pass header.i=pieter.wuille@gmail.com
Received: from mr.google.com ([10.180.107.68])
by 10.180.107.68 with SMTP id ha4mr40691552wib.9.1330447724605
(num_hops = 1); Tue, 28 Feb 2012 08:48:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.107.68 with SMTP id ha4mr32248498wib.9.1330447719927; Tue,
28 Feb 2012 08:48:39 -0800 (PST)
Received: by 10.223.88.146 with HTTP; Tue, 28 Feb 2012 08:48:39 -0800 (PST)
Date: Tue, 28 Feb 2012 17:48:39 +0100
Message-ID: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
-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: 1S2QEM-0004Ov-M5
Subject: [Bitcoin-development] Duplicate transactions vulnerability
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: Tue, 28 Feb 2012 16:48:51 -0000
Hello all,
as some of you may know, a vulnerability has been found in how the
Bitcoin reference client deals with duplicate transactions. Exploiting
it is rather complex, requires some hash power, and has no financial
benefit for the attacker. Still, it's a security hole, and we'd like
to fix this as soon as possible.
A simple way to fix this, is adding an extra protocol rule[1]:
Do not allow blocks to contain a transaction whose hash is equal to
that of a former transaction which has not yet been completely spent.
I've written about it in BIP30[2]. There is a patch for the reference
client, which has been tested and verified to make the attack
impossible. The change is backward compatible in the same way BIP16
is: if a supermajority of mining power implements it, old clients can
continue to function without risk.
The purpose of this mail is asking for support for adding this rule to
the protocol rules. If there is consensus this rule is the solution, I
hope pools and miners can agree to update their nodes without lengthy
coinbase-flagging procedure that would only delay a solution. So, who
is in favor?
[1] https://en.bitcoin.it/wiki/Protocol_rules
[2] https://en.bitcoin.it/wiki/BIP_0030
--
Pieter
|
