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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1S3Hje-0000KZ-0l
for bitcoin-development@lists.sourceforge.net;
Fri, 02 Mar 2012 01:56:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=pieter.wuille@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S3Hjd-0007ur-7O
for bitcoin-development@lists.sourceforge.net;
Fri, 02 Mar 2012 01:56:41 +0000
Received: by wgbfm10 with SMTP id fm10so38058wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 01 Mar 2012 17:56:35 -0800 (PST)
Received-SPF: pass (google.com: domain of pieter.wuille@gmail.com designates
10.180.83.42 as permitted sender) client-ip=10.180.83.42;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
pieter.wuille@gmail.com designates 10.180.83.42 as permitted
sender) smtp.mail=pieter.wuille@gmail.com;
dkim=pass header.i=pieter.wuille@gmail.com
Received: from mr.google.com ([10.180.83.42])
by 10.180.83.42 with SMTP id n10mr649109wiy.9.1330653395177 (num_hops =
1); Thu, 01 Mar 2012 17:56:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.83.42 with SMTP id n10mr520149wiy.9.1330653395070; Thu, 01
Mar 2012 17:56:35 -0800 (PST)
Received: by 10.223.88.146 with HTTP; Thu, 1 Mar 2012 17:56:34 -0800 (PST)
In-Reply-To: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
Date: Fri, 2 Mar 2012 02:56:34 +0100
Message-ID: <CAPg+sBj_zOvNS91BeAzJ8bFWmyYxk1CUhA=Y2_J8vFt4-fruyg@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: 1S3Hjd-0007ur-7O
Subject: Re: [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: Fri, 02 Mar 2012 01:56:42 -0000
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 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.
After some private discussion, Ben Reeves pointed out two potential
small weaknesses in the proposed patch, which seem viable to me.
First: disconnecting the same coinbase transaction twice would fail,
as EraseTxIndex will not find anything the second time. This is
extremely hard to pull off, as it requires reverting a chain of at
least 120 blocks long. Still, the fix is very easy imho: allow
EraseTxIndex to fail.
Second: assume the following order of events: block with coinbase A is
created, 120 blocks later, A:0 is spent in transaction B. Then, a dupe
of A is created, and another 120 blocks are waited. At this point, A:0
and B:0 are still spendable. Now a block is created with two
transactions: first C which spends B:0, followed by a dupe of B. This
dupe is accepted, as its former instance is completely spent now.
However, if this last block is disconnected again, B:0 is not
spendable anymore, causing a risk for chain split. Ben suggested
moving the check for dupes up, turning the new network rule into:
Blocks are not allowed to contain transactions whose hash matches
that of an earlier transaction in the same chain, unless that
transaction was already completely spent before said block.
I've updated the patch, and will update the BIP soon.
What do you all think? Can we still move forward with deploying this?
--
Pieter
|
