summaryrefslogtreecommitdiff
path: root/41/704e25c55e201263ab8b8bae9792f89d2ecb72
blob: 328a182ee431b47ac568a2b5c84951ae69f53384 (plain)
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
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 <pete@petertodd.org>) id 1WciHU-0003hU-PB
	for bitcoin-development@lists.sourceforge.net;
	Tue, 22 Apr 2014 21:31:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WciHR-0003P3-Dr for bitcoin-development@lists.sourceforge.net;
	Tue, 22 Apr 2014 21:31:08 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3MLUx1s083235;
	Tue, 22 Apr 2014 22:30:59 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3MLUsJR037180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 22 Apr 2014 22:30:56 +0100 (BST)
Date: Tue, 22 Apr 2014 17:31:28 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20140422213128.GB2578@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 64199e5e-ca65-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdAAUGUUGAgsB AmIbWVZeU117XGQ7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrAmF9 Y11kMBlxcAROeDBx YENqVj5dWEVzfBN4
	F1MHRGsDeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDFTpCNCY1
	WhQrMjY9PDNQYDlT SQYLI1MIREsHViIm ThYZFD4zHEoDXG0y
	NFQvYlobAA4cO14z PEFpRVIRNVcXDRZC fQlVDShBI1RJXSci CQJBUCYA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1WciHR-0003P3-Dr
Cc: support@luckyb.it
Subject: [Bitcoin-development] Double-spending unconfirmed transactions is a
 lot easier than most people realise
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, 22 Apr 2014 21:31:09 -0000


--Fba/0zbH8Xs+Fj9o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

You may have seen my reddit post of the same title a few days ago:

http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_=
transactions_is_a_lot/

I've done some more experiments since, with good results. For instance
here's a real-world double-spend of the gambling service Lucky Bit:

Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20

01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f790=
00000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c=
4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae=
8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffff=
ffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac4=
00d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000=
000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000

Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce885=
82a

01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f790=
00000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed5633=
90011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476=
d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffff=
ffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac0=
0000000

The double-spend was mined by Eligius and made use of the fact that
Eligius blacklists transactions to a number of addresses considered to
be "spam" by the pool operators; affected transactions are not added to
the Eligus mempool at all. Lucky Bit has a real-time display of bets as
they are accepted; I simply watched that display to determine whether or
not I had lost. With Eligius at 8% and the house edge at 1.75% the
attack is profitable when automated. My replace-by-fee patch(1) was
used, although as there are only a handful of such nodes running - none
connected directly to Eligius from what I can determine - I submitted
the double-spend transactions to Eligius directly via their pushtxn
webform.(2)

Of course, this is an especially difficult case, as you must send the
double-spend after the original transaction - normally just sending a
non-standard tx to Eligius first would suffice. Note how this defeats
Andresen's double-spend-relay patch(3) as proposed since the
double-spend is a non-standard transaction.

In discussion with Lucky Bit they have added case-specific code to
reject transactions with known blacklisted outputs; the above
double-spend I preformed is no longer possible. Of course, if the
(reused) Lucky Bit addresses are added to that blacklist, that approach
isn't viable - I suggest they switch to a scheme where addresses are not
reused. (per-customer? rotated?) They also have added code to keep track
of double-spend occurances and trigger human intervention prior to
unacceptable losses. Longer term as with most services (e.g. Just-Dice)
they intend to move to off-chain transactions. They are also considering
implementing replace-by-fee scorched earth(4) - in their case a single
pool, such as Eligius, implementing it would be enough to make the
attack unprofitable. It may also be enough security to allow users to
use their deposits prior to the first confirmation in a Just-Dice style
off-chain implementation.

1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1

2) http://eligius.st/~wizkid057/newstats/pushtxn.php

3) https://github.com/bitcoin/bitcoin/pull/3354 and
   https://github.com/bitcoin/bitcoin/pull/3883

4) https://bitcointalk.org/index.php?topic=3D251233.msg2669189#msg2669189

--=20
'peter'[:-1]@petertodd.org
000000000000000024abc60eebba42333d74b30635ca5fb0b7c776a579c307a8

--Fba/0zbH8Xs+Fj9o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTVt+sXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA4NGRhZWM1MDRmOWY0OWI5YjJiMjcyNDdmOTZlNTY2ZGI0
ZTZhOThmNDA2ODM0OGMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftDDAf/eoNF4xWQFhNVhsEowegwj+TR
TGbGGvxtU/xadYVgPEaBdxRVmR8H8FFt3JUra0fMnianN/vKfpGMUB5L9rGUVr7C
eU+rwIMePFYLI++ckqh2rSpmk99DdAac8glmUJYTVgChMNzwp5OBncDPZBlC/l1m
bXtf7z1DPe07hTu/uQs0JajiZSn5adpGfKlFgHVY6jkxYVuSp4/yGo382WgpXjZ1
5ng4O8hEGqvBJRM5VUw1qsPuSqJWgCmNUnNXjrysWvrSY0zmuCyPBMok8Pd7uhjH
ZAlQBfzGfzDza7DnZYMB2Xw49Fzl2f2Kf055OsJEunHu3GAjqNeOY0RZI+HPFw==
=/XNK
-----END PGP SIGNATURE-----

--Fba/0zbH8Xs+Fj9o--