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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdkDa-0006MQ-7b
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 17:15:06 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdkDY-0005Gu-Uv for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 17:15:06 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA5HErH0066903;
Tue, 5 Nov 2013 17:14:53 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 rA5HEkaA071005
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 5 Nov 2013 17:14:49 GMT
Date: Tue, 5 Nov 2013 12:14:45 -0500
From: Peter Todd <pete@petertodd.org>
To: Ittay <ittay.eyal@cornell.edu>
Message-ID: <20131105171445.GA13710@petertodd.org>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
<20131105170541.GA13660@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy"
Content-Disposition: inline
In-Reply-To: <20131105170541.GA13660@petertodd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: c72aed2b-463d-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdgcUFloCAgsB AmUbWlNeUVl7XWo7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20E fmtFA2hycARGeHs+ ZE9kV3AVD0N4JBMp
QBxJEWsFMXphaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E DwgYGi0oBkQBD2B7
NxU6IV5UAEFZKEwz KlZpQl8cPR4JCm8W GkBLASlWb0UBXScw DQReUQh2
X-Authentic-SMTP: 61633532353630.1024: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.
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]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VdkDY-0005Gu-Uv
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Gavin Andresen <gavin@bitcoinfoundation.org>,
Emin =?iso-8859-1?B?R/xu?= Sirer <egs@systems.cs.cornell.edu>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish
mining threshold.
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: Tue, 05 Nov 2013 17:15:06 -0000
--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> > Hello,
> >=20
> > Please see below our BIP for raising the selfish mining threshold.
> > Looking forward to your comments.
>=20
> <snip>
>=20
> > 2. No new vulnerabilities introduced:
> > Currently the choice among equal-length chains is done arbitrarily,
> > depending on network topology. This arbitrariness is a source of
> > vulnerability. We replace it with explicit randomness, which is at the
> > control of the protocol. The change does not introduce executions that =
were
> > not possible with the old protocol.
>=20
> Credit goes to Gregory Maxwell for pointing this out, but the random
> choice solution does in fact introduce a vulnerability in that it
> creates incentives for pools over a certain size to withhold blocks
> rather than immediately broadcasting all blocks found.
>=20
> The problem is that when the pool eventually choses to reveal the block
> they mined, 50% of the hashing power switches, thus splitting the
> network. Like the original attack this can be to their benefit. For
> pools over a certain size this strategy is profitable even without
> investing in a low-latency network; Maxwell or someone else can chime in
> with the details for deriving that threshold.
>=20
> I won't get a chance to for a few hours, but someone should do the
> analysis on a deterministic switching scheme.
Oh, and I don't want to give the wrong impression: there's no need to
rush to get this problem fixed. Even if someone wanted to launch an
attack right now, with a fair amount of resources, there's a lot of
counter-measures based on human intervention that can definitely stop
the attack in the short-term; what's needed is at worst moderate-term,
and much more likely a long-term approach. In addition, keep in mind
that this attack is very easy to detect, so if one is actually launched
we will know immediately and can start taking direct counter-measures at
that time.
That Gregory Maxwell so quickly identified a flaw in this proposed
solution suggests we should proceed carefully.
It'd be good to do a test of this attack, as well as possible solutions,
on testnet to better explore it and possible counter-measures.
--=20
'peter'[:-1]@petertodd.org
000000000000000a03ea8c90161a275ee63d077ec35c1b582c77934c0be12a02
--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSeSeFAAoJEBmcgzuo5/CF+AgH+weDKQ5U5NcODVhuweE9sOfF
EeFMrK2dVhvqu6diDOP+U47Gwf7Lf43BdbgMoZ4E0sUwpow7MMoyO+2kJa587zYA
Lts6os4tVgT3R2QKLdnmVaJ8rL5SdiHcWZQk2GI6FXDD+4jeMZuEr0xSAEa8RFHb
oU5w8vz0MkP2GJHOtVMfBFPHz08jGUFH5c4+z20aY2MHdRyYLrcKLbDJj7Rlq797
WIL4rdCjkn+Td59hoHi+TWjS2rNjp+i3SQTvv8UxD6uG4FO+yGDJX/pKEng529x9
Do39p+hUsJx86WxYbjDwbNRmeoB/9nUvRO7K0AfDsgE6zpK5U2/bG4iVMlK4+ds=
=rQWy
-----END PGP SIGNATURE-----
--gBBFr7Ir9EOA20Yy--
|
