summaryrefslogtreecommitdiff
path: root/fc/c39019677f6cff90ae6ace95f821c5972bc60b
blob: 9519f14b526673001d6ce2fac15e02bd2a89211c (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
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!