Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.182 as permitted sender)
	client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f182.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
Date: Mon, 4 Nov 2013 12:26:30 +0100
Message-ID: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133177c0605cf04ea5830bb
Subject: [Bitcoin-development] Auto-generated miner backbone
Precedence: list

--001a1133177c0605cf04ea5830bb
Content-Type: text/plain; charset=UTF-8

W.R.T. this paper and the oft-discussed miner backbone,

  http://arxiv.org/pdf/1311.0243v1.pdf

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?

This would have the effect of automatically linking all the major pools
together, with no administration overhead.

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

It feels like this should be achievable with a few days of solid coding and
a couple of new command line flags, and the impact is much easier to reason
about than a fundamental rule change like the one proposed by the paper.

--001a1133177c0605cf04ea5830bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">W.R.T. this paper and the oft-discussed miner backbone,<di=
v><br></div><div>=C2=A0=C2=A0<a href=3D"http://arxiv.org/pdf/1311.0243v1.pd=
f">http://arxiv.org/pdf/1311.0243v1.pdf</a><br></div><div><br></div><div>I&=
#39;m wondering about an alternative protocol change that perhaps has less =
subtle implications than their suggested change. Rather than address the pr=
oblem 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 automat=
ically build a miner backbone by having IP addresses of nodes embedded into=
 coinbases, then having any bitcoind that is creating work automatically co=
nnect to IPs that appeared in enough recent blocks?=C2=A0</div>
<div><br></div><div>This would have the effect of automatically linking all=
 the major pools together, with no administration overhead.</div><div><br><=
/div><div>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 re=
ached via Tor. This might be useful in the case of pools that don&#39;t to =
reveal the location of their bitcoin node[s], like for anti-DoS reasons.</d=
iv>
<div><br></div><div>It feels like this should be achievable with a few days=
 of solid coding and a couple of new command line flags, and the impact is =
much easier to reason about than a fundamental rule change like the one pro=
posed by the paper.</div>
</div>

--001a1133177c0605cf04ea5830bb--