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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdLhg-0002y1-Sa
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:04:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdLhe-0006DC-MK for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:04:32 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4F4I2u023007;
Mon, 4 Nov 2013 15:04:18 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 rA4F46bS058617
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 15:04:09 GMT
Date: Mon, 4 Nov 2013 10:04:06 -0500
From: Peter Todd <pete@petertodd.org>
To: Ittay <ittay.eyal@cornell.edu>
Message-ID: <20131104150406.GA2566@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104142621.GA2190@petertodd.org>
<CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline
In-Reply-To: <CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 5b818b02-4562-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmUbWlFeUFl7WWo7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20F cBoYAHpycg1AeXk+ ZEJrX3YVWRZydE4v
QkxJEWgAZ3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNyMg QFUNEDMiB0QZSil7
Kh0gJ0RUFk8aMU81 N1ZJ
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.
-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: 1VdLhe-0006DC-MK
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 15:04:33 -0000
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 09:49:09AM -0500, Ittay wrote:
> 1. Something important that is being overlooked is that the attack is
> relevant even without the sybil attack. Even if you assume the selfish
> miners loose every time on a 1:1 competition, they can still benefit in
> pools larger than 33%. And pools often reach this size.
>=20
> 2. The selfish pool can essentially hide its behavior behind multiple IP
> addresses. I fear employing an anti-sybil mechanism of this sort may expo=
se
> new vulnerabilities. The current approach is great - the attacker cannot
> partition the network, only gain a slight timing advantage. Our approach
> just takes away the network-induced arbitrariness and replaces it with
> explicit randomness, which cannot introduce new vulnerabilities. It
> protects us from 25% attacks, which is excellent (though unfortunately not
> as good as the 51% security we believed before).
The problem is picking which side of the fork you mine on randomly isn't
rational for an individual miner. The time that you heard about a block
is important information: the block you heard about first is more likely
to have propagated to the majority of the hashing power than the one you
learn about second. You're rational incentive is to always mine on the
majority side as that side has the highest probability of no competing
blocks being found when the next block is found. (with the one exception
of the previous block being yours) In addition the next block found will
propagate to the majority of hashing power faster, as that majority
already has the previous block. By suggesting that miners pick randomly
half the time they will be going against their best interests. (if not
the interests of the network as a whole)
On the other hand my near-target broadcast solution gives miners honest
proof of what the majority actually is. Making use of that information
is the economically rational choice even at an individual level. Yet it
still defeats the attack, and it does better in returning the threshold
to the originally assumed 51% level.
--=20
'peter'[:-1]@petertodd.org
0000000000000005fa5454135b2638d1b2240d565737a24586f31490025e2de0
--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSd7dmAAoJEBmcgzuo5/CFQwEIAICZtsfJLVVAi2BX3ZBZdZdF
jxWbaXX2xg3R7Vy8Gcx7Xh8KthoLNshu+uTGBQo0xFbCDPiH9D5qpa7gWDZdMTgl
ytfpOE9rW6vnKv72LW872boxDO9TemT3voU3KD8yW69wnl1n/i04gFY0mtOZOWJn
DXGiSZs9++mO0TLDoWd1TU9krf6sx1EfeZ25gjoHXcAlWvVNKNzRi9wcpwfR57wA
xpY8Vu+S/ToIqmuird+/gFjojy8oOFGCghSEdtXVCdVb12CBQxvKM+HEkbIJfHzv
hDa4nlQq8Nt2jNsCcSfmp/uaVJ3gOrQOmxUAr1gPcF70fma0iB7FtcHXq7T6p6k=
=wPe4
-----END PGP SIGNATURE-----
--X1bOJ3K7DJ5YkBrT--
|
