Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Date: Mon, 4 Nov 2013 06:53:14 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131104115314.GA1013@savin>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Precedence: list


--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
> W.R.T. this paper and the oft-discussed miner backbone,
>=20
>   http://arxiv.org/pdf/1311.0243v1.pdf
>=20
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change. Rather than address the
> problem by assuming the network is full of sybil nodes and changing the
> rules for selecting the chain to build on, how about if we wrote code to
> automatically build a miner backbone by having IP addresses of nodes
> embedded into coinbases, then having any bitcoind that is creating work
> automatically connect to IPs that appeared in enough recent blocks?

I proposed this as a means of giving a mechanism for wallets to get
non-sybilled peers as well.

> This would have the effect of automatically linking all the major pools
> together, with no administration overhead.
>=20
> For bonus points, the IPs could be IPv6 and then the trick we use to pack
> hidden services into IPv6 address space would allow nodes to be reached v=
ia
> Tor. This might be useful in the case of pools that don't to reveal the
> location of their bitcoin node[s], like for anti-DoS reasons.
>=20
> It feels like this should be achievable with a few days of solid coding a=
nd
> a couple of new command line flags, and the impact is much easier to reas=
on
> about than a fundamental rule change like the one proposed by the paper.

Doing so encourages pools to only bother connecting to other pools,
which is a strong centralizing force. But given the nasty incentives
present anyway - it's in your advantage to distribute your blocks to no
more than a majority of hashing power if you can do so consistently -
I'm unconvinced that this won't happen anyway.

The maximal benefit would be if two sets of addresses were published:
public and private. The issue with publishing addresses is DoS attacks,
but publishing Tor addresses doesn't stop attacks. What would discourage
attacks however would be to encrypt that data such that only the
creators of specific prior blocks could decrypt it. This limits the
audience to those with incentives not to commit a DoS attack. (DoS
attack the IP, and you'll no longer get preferential peering)

Say what you want about centralization, but for the pools involved it's
a good idea.


On a technical level, the coinbase is limited in size, and people use it
for other purposes, so lets define a standard where this data is stored
in an OP_RETURN txout of the form:

OP_RETURN <key> <value> <key> <value> ...

Multiple values with the same key should be allowed. This data should be
placed in the last txout so that SPV nodes can eventually be given it
with a SHA256 midstate.

--=20
'peter'[:-1]@petertodd.org
00000000000000080e395c361bdf9db583d5f4c0e144f476c229285b15eae59c

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJSd4qqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMGE2ZGQ5NmM1NTFlY2E3Mjk5NDYzZTRlNTIzNDYyNzk4YTAw
NjUzNWY0MTJiNTE5YzcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfurmQf/SQOlv6xWFDlco0Kc6PeawDJF
eJ39EqKZ5rqxkIVMspJtBXrg30+aF/ZeU2fQIfRRSi5iED1exTm+y+a5trXhrm2A
PUNMLBEhztemzC+7B8HOZ983Pm7YHMO57xiuDHXDjbwdRPeq0cxkLG4PqxUnzMzB
jNII1PXLjpD9z9M3PAHVugcEboqiuaXgKvoP5gMMjliFrjwT14V5Ojai/tjfb4YS
sZKH5xWYQlGSPZFW4Qp0TDOUuQXmo8gDlkTZHUs3q4pvri6HKEOPQv4TlUNijxhV
iEwfEmy4wBk3QMEjl8M1RTMREN7r/CqsfKey9xc/fMU8ViQzBmXvN2xtZajIBw==
=6FFl
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--