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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdMgi-0006zS-Qx
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 16:07:36 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdMgf-0007a2-B5 for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 16:07:36 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt5.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4G7LUg035970;
Mon, 4 Nov 2013 16:07:21 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 rA4G7GgB065355
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 16:07:19 GMT
Date: Mon, 4 Nov 2013 11:07:16 -0500
From: Peter Todd <pete@petertodd.org>
To: Ittay <ittay.eyal@cornell.edu>
Message-ID: <20131104160716.GA3052@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104142621.GA2190@petertodd.org>
<CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
<20131104150406.GA2566@petertodd.org>
<CABT1wWmONUeOWRg-=FKr88bgBQf0un4bvjYW2h8d-10ys-VKtA@mail.gmail.com>
<20131104154639.GB2759@petertodd.org>
<CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2eb58f23-456b-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmUbWlJeUFp7WGo7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20F cRlpBWtycQBFfXs+ ZEBlWnQVXhEocE4r
QE1JEWgAN3phaTUc 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: 1VdMgf-0007a2-B5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Emin =?iso-8859-1?B?R/xu?= Sirer <egs@systems.cs.cornell.edu>
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 16:07:37 -0000
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
(not sure if you meant this to go to the list, my apologies if not)
On Mon, Nov 04, 2013 at 10:50:25AM -0500, Ittay wrote:
> On Mon, Nov 4, 2013 at 10:46 AM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > On Mon, Nov 04, 2013 at 10:25:19AM -0500, Ittay wrote:
> > > Peter - how can you guarantee that the majority mines on the non-self=
ish
> > > block?
> >
> > Of course, it may be the case that competing near-block headers are
> > found, but no matter: as long as miners switch to the block with the
> > most hashing power, this forms a feedback effect that quickly brings
> > everyone to consensus. With everyone mining to extend the same block,
> > there's nothing the selfish miner can do; there's no disagreement to
> > exploit.
> >
>=20
> This is not the exploit! The majority you create might just as well follow
> the previously-private block, so we're back in square one.
Right, but the thing is, if all miners quickly come to consensus and are
all mining on the same block, there's nothing the attacker can exploit
in the first place.
Suppose Alice the attacker is 100 blocks ahead of the main network
somehow. We'll say the other miners are working to extend block n, and
she's in posession of 100 blocks extending that. She also has just under
50% of the hashing power.
Now when the main network finds a block n+1, Alice can do one of two
things: she can publish her own n+1 block, or she can do nothing. If she
does nothing, the main network will find block n+2 faster than she finds
n+101, so eventually she loses. Thus she has to publish.
In your attack she publishes to a subset of nodes strategicly, splitting
the hashing power between nodes working to extend her n+1, and the other
n+1 found. However, with near-target headers, very quickly all hashing
power will come to consensus and all work to extend the same block,
either theirs or Alice's. Given that they have the majority, they will
find another block faster on average than Alice can extend her lead, and
thus eventually Alice will lose.
Now there is still a slight advantage for Alice in that it takes some
time for the whole network to come to consensus, but this is a much
slimmer margin, maybe a few percentage points, so at best Alice might
need, say, 45% of the total hashing power.
--=20
'peter'[:-1]@petertodd.org
0000000000000004b8381fe97338c8b710cb662160f08e391820f30a375bb9b9
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSd8Y0AAoJEBmcgzuo5/CFfH8IAJqShGi0wQmKinI0Lrcyrcry
cdzdq2gc19xErlh0QXYjLt2XI5vve6k1jkYKuHJQsmDHAA7UZTFZAL5V4RT4fifx
l81o8r43wzqScQ8xWllRwNyIH4gXVNBrvUH1pe462/EaSJkhnkas8xrWVnVz1U4U
C9RSzw60SY6Th+lDEePv4ekaVvgtHgx6av8y9n/G/y/xRQKopL4do//FVQLuGXgJ
e/1BcCFsMLVHBSAF36Deo4IWZLw61Eo3EnIFbFV5YcmPL4ULUwWw9WLr0x8lN/JE
wjnj2V8+FuuQ2FimrpCjC25dL8A6HCuJCwp+wAuv7c4pyCnzUM1oukgYNma4HBQ=
=JBxm
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
|
