From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Cc: support@luckyb•it
Subject: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
Date: Tue, 22 Apr 2014 17:31:28 -0400 [thread overview]
Message-ID: <20140422213128.GB2578@savin> (raw)
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
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
01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000
Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a
01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac00000000
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=251233.msg2669189#msg2669189
--
'peter'[:-1]@petertodd.org
000000000000000024abc60eebba42333d74b30635ca5fb0b7c776a579c307a8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next reply other threads:[~2014-04-22 21:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 21:31 Peter Todd [this message]
2014-04-23 4:29 ` Jan Møller
2014-04-23 6:35 ` Mark Friedenbach
2014-04-23 4:45 ` Tom Harding
2014-04-23 4:03 ` Matt Whitlock
2014-04-23 22:29 ` Tom Harding
2014-04-24 0:42 ` Simon Barber
2014-04-23 4:22 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140422213128.GB2578@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=support@luckyb$(echo .)it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox