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; 
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)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Precedence: list


--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--