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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <support@pi.uk.com>) id 1S2UEx-0004fp-6X
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 21:05:43 +0000
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S2UEw-0007Ub-4v
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 21:05:43 +0000
Received: by wera1 with SMTP id a1so2296872wer.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Feb 2012 13:05:36 -0800 (PST)
Received-SPF: pass (google.com: domain of support@pi.uk.com designates
10.180.86.9 as permitted sender) client-ip=10.180.86.9;
Authentication-Results: mr.google.com;
spf=pass (google.com: domain of support@pi.uk.com
designates 10.180.86.9 as permitted sender)
smtp.mail=support@pi.uk.com
Received: from mr.google.com ([10.180.86.9])
by 10.180.86.9 with SMTP id l9mr42686381wiz.15.1330463136053 (num_hops
= 1); Tue, 28 Feb 2012 13:05:36 -0800 (PST)
Received: by 10.180.86.9 with SMTP id l9mr33774699wiz.15.1330461307920;
Tue, 28 Feb 2012 12:35:07 -0800 (PST)
Received: from [192.168.2.207] (52.238.187.81.in-addr.arpa. [81.187.238.52])
by mx.google.com with ESMTPS id 9sm52708251wid.2.2012.02.28.12.35.06
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 28 Feb 2012 12:35:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407"
From: Ben Reeves <support@pi.uk.com>
In-Reply-To: <201202281323.02976.luke@dashjr.org>
Date: Tue, 28 Feb 2012 20:35:05 +0000
Message-Id: <736F8531-28F8-4219-9DE9-3F201FC7DCF4@pi.uk.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
<201202281323.02976.luke@dashjr.org>
To: Luke-Jr <luke@dashjr.org>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnmoW+wsYAdWurtnKsbUL6H0GTZWJpiZt4+xVR+6yQgRwKOQmsaKNCoExJvWkMcXzMNEsrs
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
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1S2UEw-0007Ub-4v
Cc: bitcoin-development@lists.sourceforge.net
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: Tue, 28 Feb 2012 21:05:43 -0000
--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I might be wrong but I think perhaps it would help to get this fix out =
before the p2sh protocol change. Otherwise a miner could combine a =
duplicate coinbase and an invalid P2SH transaction to create a block =
which can have excellent network propagation and still be guaranteed to =
be orphaned. This makes the attack significantly easier to perform.
If someone were to do this on the day of the P2SH switchover they could =
corrupt the database of all clients < 0.6 with only a single block. If =
it was done on an early block and was widespread enough it would make it =
difficult for new clients to find a genuine non-corrupted copy of the =
blockchain to download.
Thank You,
Ben Reeves
www.blockchain.info
On 28 Feb 2012, at 18:23, Luke-Jr wrote:
> On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>=20
>> 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.
>>=20
>> 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.
>=20
> Has it been verified to make even rocconor's complicated =
transaction-based=20
> version impossible?
>=20
>> 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?
>=20
> Can we do this in two steps? First, prefer blocks which don't break =
the rule;=20
> once 55%+ are confirmed to have upgraded, then it is safe to treat it =
as a=20
> hard rule.
>=20
> =
--------------------------------------------------------------------------=
----
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft =
developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, =
MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>I =
might be wrong but I think perhaps it would help to get this fix out =
before the p2sh protocol change. Otherwise a miner could combine a =
duplicate coinbase and an invalid P2SH transaction to create a block =
which can have excellent network propagation and still be guaranteed to =
be orphaned. This makes the attack significantly easier to =
perform.<br><br>If someone were to do this on the day of the P2SH =
switchover they could corrupt the database of all clients < 0.6 with =
only a single block. If it was done on an early block and was widespread =
enough it would make it difficult for new clients to find a genuine =
non-corrupted copy of the blockchain to download.<br><br>Thank =
You,<br>Ben Reeves<br><a =
href=3D"http://www.blockchain.info/">www.blockchain.info</a><div><br></div=
><div><br><div><div>On 28 Feb 2012, at 18:23, Luke-Jr wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille =
wrote:<br><blockquote type=3D"cite">A simple way to fix this, is adding =
an extra protocol rule[1]:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> Do not =
allow blocks to contain a transaction whose hash is equal =
to<br></blockquote><blockquote type=3D"cite">that of a former =
transaction which has not yet been completely =
spent.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I've written =
about it in BIP30[2]. There is a patch for the =
reference<br></blockquote><blockquote type=3D"cite">client, which has =
been tested and verified to make the attack<br></blockquote><blockquote =
type=3D"cite">impossible.<br></blockquote><br>Has it been verified to =
make even rocconor's complicated transaction-based <br>version =
impossible?<br><br><blockquote type=3D"cite">The purpose of this mail is =
asking for support for adding this rule to<br></blockquote><blockquote =
type=3D"cite">the protocol rules. If there is consensus this rule is the =
solution, I<br></blockquote><blockquote type=3D"cite">hope pools and =
miners can agree to update their nodes without =
lengthy<br></blockquote><blockquote type=3D"cite">coinbase-flagging =
procedure that would only delay a solution. So, =
who<br></blockquote><blockquote type=3D"cite">is in =
favor?<br></blockquote><br>Can we do this in two steps? First, prefer =
blocks which don't break the rule; <br>once 55%+ are confirmed to have =
upgraded, then it is safe to treat it as a <br>hard =
rule.<br><br>-------------------------------------------------------------=
-----------------<br>Keep Your Developer Skills Current with =
LearnDevNow!<br>The most comprehensive online learning library for =
Microsoft developers<br>is just $99.99! Visual Studio, SharePoint, SQL - =
plus HTML5, CSS3, MVC3,<br>Metro Style Apps, more. Free future releases =
when you subscribe now!<br><a =
href=3D"http://p.sf.net/sfu/learndevnow-d2d">http://p.sf.net/sfu/learndevn=
ow-d2d</a><br>_______________________________________________<br>Bitcoin-d=
evelopment mailing =
list<br>Bitcoin-development@lists.sourceforge.net<br>https://lists.sourcef=
orge.net/lists/listinfo/bitcoin-development<br></div></blockquote></div><b=
r></div></body></html>=
--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407--
|
