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-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdL78-0001aW-78
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 14:26:46 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.111 as permitted sender)
client-ip=62.13.148.111; envelope-from=pete@petertodd.org;
helo=outmail148111.authsmtp.net;
Received: from outmail148111.authsmtp.net ([62.13.148.111])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdL76-0003ms-GX for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 14:26:46 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt8.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4EQWJ5000477;
Mon, 4 Nov 2013 14:26:32 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4EQLBS063523
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 14:26:24 GMT
Date: Mon, 4 Nov 2013 09:26:21 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>, Ittay Eyal <ittay.eyal@cornell.edu>
Message-ID: <20131104142621.GA2190@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 15d8f42b-455d-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmUbWlBeUlt7W2Y7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20F c39iIHpycQZDen0+ ZE9kVnQVXUEufRB5
QBxJEWgDMXphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNyMg QFUNEDMiB0QZSil7
Kh0gJ0RUFk8aMU81 N1ZJ
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
X-Headers-End: 1VdL76-0003ms-GX
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
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: Mon, 04 Nov 2013 14:26:46 -0000
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
> W.R.T. this paper and the oft-discussed miner backbone,
>=20
> http://arxiv.org/pdf/1311.0243v1.pdf
>=20
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change. Rather than address the
> problem by assuming the network is full of sybil nodes and changing the
> rules for selecting the chain to build on, how about if we wrote code to
> automatically build a miner backbone by having IP addresses of nodes
> embedded into coinbases, then having any bitcoind that is creating work
> automatically connect to IPs that appeared in enough recent blocks?
>=20
> It feels like this should be achievable with a few days of solid coding a=
nd
> a couple of new command line flags, and the impact is much easier to reas=
on
> about than a fundamental rule change like the one proposed by the paper.
Actually on further reflection this idea will make the attack described
in the paper easier to carry out, rather than harder.
I think where you're misunderstanding originates is the description of
this attack as requiring a sybil attack on the network - you see this
underlying sybil as one of numerical advantage, when it's actually one
of *informational* advantage.
Remember that the selfish miner strategy outlined in the paper is
essentially a way to use knowledge of what blocks miners will be mining
on, from the "first seen" rule, and the ability to broadcast blocks you
have mined more widely than other miners. That knowledge and ability is
then used in conjunction with a small lead (obtainable by chance) to
outpace the rest of the network.
By making all miners easily identifiable you make gaining that
informational and broadcast capability easier to obtain rather than
harder. The attacker now only needs to connect to every identified miner
with especially fast nodes. With judicious use of DoS attacks and low
latency they can still gain the informational and broadcast "upper hand"
over other miners and carry out the attack.
Where the paper goes wrong is they don't recognize the fundemental
nature of the strategy being based on an informational advantage. Their
"pick a random side of the fork" strategy may work to some extent, but
it's incomplete and isn't necessarily rational for the miners
individually.
The correct, and rational, approach for a miner is to always mine to
extend the block that the majority of hashing power is trying to extend.
The current relay rules don't give you that information at all, but they
can if we do two things:
1) Relay all blocks that meet the PoW target. (as suggested in the
paper)
2) Relay block headers that nearly meet the PoW target.
Mining strategy is now to mine to extend the first block you see, on the
assumption that the earlier one probably propagated to a large portion
of the total hashing power. But as you receive "near-blocks" that are
under the PoW target, use them to estimate the hashing power on each
fork, and if it looks like you are not on the majority side, switch.
This very effectively defeats the paper's selfish-miner strategy, as all
miners will very quickly be mining on the block that truly has the
majority of hashing power trying to extend it. This is also a better
overall outcome, because it puts the 51% attack threshhold back at 51%
--=20
'peter'[:-1]@petertodd.org
0000000000000004ee9bb13b022c412d75692b5e85454013c53f89e5d6fa8c69
--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSd66NAAoJEBmcgzuo5/CFAIcH/2M7X68XC4hQj77H6yPslS03
lYcShJL1P8Ya5WyPgDuxF5coICDlI6EN0au+peNqr1Vby5jVfFrYByVeVWWH16vf
b5yLYwfV9YglGr8Oavnq7ywMvWGW1luoZrOI+qVH6crdHiD7N2DG3XG8NHd0n/+h
1VziCoXgeoHq9MX3HyRzqh+igTgS1KzGskG/e10TTG0txjbrEsA08zETkALfdx8W
8VBbeYMmrxgaQb2MsJc9lsyBQtE//lgue03Eiab2y3XHmRvtUy3rFaRvTRoa9VLt
CLEWXCk8+5rDgIQTmo/CgRK8Q62jbMnZya1LLCd5JZxLkZHhIY0OomSNr13u82w=
=MSPd
-----END PGP SIGNATURE-----
--a8Wt8u1KmwUX3Y2C--
|
