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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdSFG-000103-WA
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 22:03:39 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.107 as permitted sender)
client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
helo=outmail148107.authsmtp.com;
Received: from outmail148107.authsmtp.com ([62.13.148.107])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdSFE-0001f3-NC for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 22:03:38 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4M3TFr038614;
Mon, 4 Nov 2013 22:03:29 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 rA4M3Hww047340
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 22:03:20 GMT
Date: Mon, 4 Nov 2013 17:03:17 -0500
From: Peter Todd <pete@petertodd.org>
To: Alan Reiner <etotheipi@gmail.com>
Message-ID: <20131104220317.GC4443@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>
<CABT1wWmwb17b4ACHMmDKqd94tUSKsvwAPx344mZ0VS+47myeWg@mail.gmail.com>
<20131104210451.GA4443@petertodd.org> <52781574.1000904@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C"
Content-Disposition: inline
In-Reply-To: <52781574.1000904@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: ea979058-459c-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgYUFloCAgsB AmUbWVZeUF57W2M7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20F ex1mFV5ycwJFfH4+ ZEVnV3MVCRVzck99
R0ZJEWgPNnphaTUc 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: 1VdSFE-0001f3-NC
Cc: 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 22:03:39 -0000
--NU0Ex4SbNnrxsi6C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 04:45:24PM -0500, Alan Reiner wrote:
> So given the assumption that Alice is "well-connected" as Peter
> mentioned, it seems like this is a concern. But is this a realistic
> assumption? All miners have an incentive to be thoroughly connected to
> one another, to make sure they minimize the amount of time they spend
> mining on forks and that their blocks win with minimal chance of being
> orphaned. Is it realistic that one miner can somehow monopolize the
> good connections when the big miners are already trying to do the same
> thing for honest reasons? If you have a network full of honest miners
> and this one selfish-miner, it seems that all the honest miners need to
> do is try to establish those connections to each other as well as Alice
> does, and Alice will end up orphaning all her profit away.
Right, but as I said, I think this is likely to become a contest of who
can create the lowest latency mining operation, or to be more precise,
who can get the best ratio of latency per dollar.
Unfortunately even with totally "honest" mining winning orphan rates is
a function of latency; what this paper has done is mainly show a
remarkably effective way of leveraging low-latency and very good
visibility to the network.
Regardless, globe-spanning low-latency networks cost a lot of money, so
if they are something that makes mining more profitable, for whatever
reason, that's an effect that will incentivise pools to grow larger and
more centralized.
> Furthermore, you can de-incentivize it by simply randomizing the order
> of broadcasts. Although you are maintaining multiple concurrent
> connections, the data still exits your network card as a serial stream
> of packets, and it seems that if you randomize who gets your new-block
> broadcasts first, then it further reduces the Alice's advantage if she's
> not guaranteed to "be first." Sure, she can do it sometimes, but it
> would seem that even a couple failures to beat the rest of the network
> is going to erase most/all of what she gained on the blocks/chains that
> she wins.
Yeah, there's a lot of possible solutions, but what I'm seeing looking
at them is they all tend to be not economically rational, in the short
term, or even worse, they actually incentivize mining pools to get
larger. For instance anything that tries to prevent Alice from sybiling
the network by forcing nodes to prove they have mining capacity just
means that larger miners will have an advantage over smaller ones in
getting their blocks propagated as fast as possible. Once Alice does
have a reasonable amount of mining capacity, she can still use the
selfish miner attack to grow larger and more profitable.
--=20
'peter'[:-1]@petertodd.org
000000000000000aae6d13639c5b4555eeda301ebcbc53f12e8a633e267c8331
--NU0Ex4SbNnrxsi6C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSeBmlAAoJEBmcgzuo5/CFn7oH/jKrbWtnagLklYqVTvuJFuye
O0XGvaUePp2hu+Y/021URLiDQ3Yq3JrarXy+NDcceGNAnUwXFPE4qRns/17CYc9O
NkMgVczLkz8YBcHuPfcZX0w/GyxjG+u/VkaYXLflhvWIx8+AD8OES4DbNh+ld/zV
nGpP+B2WTEZaiS527z2nx2Ml1IdpkLhV+Mc5GEf5Nq/0EU+9mG6Zd12vgNc3G4tc
Q0lpxQcLBQm7mvQDObn4elhAQwMCWZYnsy9CEl60o7lo0/AM6DdvJMHhe71notiq
mubz+FBKKVM89qsavqHznhNky1bzEXLnD1CB6LJYQ9VtQ2x38dDyljjX2pZdZIo=
=5YQI
-----END PGP SIGNATURE-----
--NU0Ex4SbNnrxsi6C--
|
