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
|
Return-Path: <simongreen@airmail.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4E68273
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2015 03:38:38 +0000 (UTC)
X-Greylist: delayed 00:09:10 by SQLgrey-1.7.6
Received: from cock.li (cock.li [176.9.0.140])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E4A8ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2015 03:38:38 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 15 Jul 2015 03:29:25 +0000
From: simongreen@airmail.cc
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <24662b038abc45da7f3990e12a649b8a@airmail.cc>
X-Sender: simongreen@airmail.cc
User-Agent: Roundcube Webmail/0.9.5
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Significant losses by double-spending unconfirmed
transactions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2015 03:38:38 -0000
With my black hat on I recently performed numerous profitable
double-spend attacks against zeroconf accepting fools. With my white hat
on, I'm warning everyone. The strategy is simple:
tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
anything that miners don't always accept.
tx2: After merchant gives up valuable thing in return, normal tx without
triggering spam protections. (loltasticly a Mike Hearn Bitcoin XT node
was used to relay the double-spends)
Example success story: tx1 paying Shapeshift.io with 6uBTC output is not
dust under post-Hearn-relay-drop rules, but is dust under
pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not
paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all
miners who have reverted Hearn's 10x relay fee drop as recommended by
v0.11.0 release notes and accept these double-spends. Shapeshift.io lost
~3 BTC this week in multiple txs. (they're no longer accepting zeroconf)
Example success story #2: tx1 with post-Hearn-relay drop fee, followed
by tx2 with higher fee. Such stupidly low fee txs just don't get mined,
so wait for a miner to mine tx2. Bought a silly amount of reddit gold
off Coinbase this way among other things. I'm surprised that reddit
didn't cancel the "fools-gold" after tx reversal. (did Coinbase
guarantee those txs?) Also found multiple Bitcoin ATMs vulnerable to
this attack. (but simulated attack with tx2s still paying ATM because
didn't want to go to trouble of good phys opsec)
Shoutouts to BitPay who did things right and notified merchant properly
when tx was reversed.
In summary, every target depending on zeroconf vulnerable and lost
significant sums of money to totally trivial attacks with high
probability. No need for RBF to do this, just normal variations in miner
policy. Shapeshift claims to use Super Sophisticated Network Sybil
Attacking Monitoring from Blockcypher, but relay nodes != miner policy.
Consider yourself warned! My hat is whiter than most, and my skills not
particularly good.
What to do? Users: Listen to the experts and stop relying on zeroconf.
Black hats: Profit!
|