Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.176 as permitted sender)
	client-ip=209.85.217.176; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
Date: Mon, 4 Nov 2013 07:51:07 -0800
Message-ID: <CAAS2fgQsq0XWb7FZRFrJUmorQfeS=xXa-R4LWneq2LS48tFmng@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Precedence: list

On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn <mike@plan99.net> wrote:
> 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?

Yea, I've proposed this too (both in the past and in the context of
this). I don't think, however, that the announcements need to be the
miners themselves=E2=80=94 but instead just need to be nodes that the miner=
s
think are good (and, for their own sake=E2=80=94 ones they're well connecte=
d
to).

Miner's could keep a list of address messages nodes they
like/are-connected to, perhaps prioritizing their own nodes, than
exclude ones which are already in the most recent blocks, and include
the best remaining. Of course, if it's using address messages (or
perhaps a new address message syntax) it would automatically support
hidden services.

They should probably be included as OP_RETURN outputs in coinbase
transactions, maybe only limited (by what other clients pay attention
to) to one or two per block.

This should make it harder to get partitioned from the majority
hashrate (or partition the majority hashrate from itself), though
these hosts would be DOS targets, so it isn't a silver bullet.

Making the majority hashrate self-unpartitionabilty stronger is
possible=E2=80=94 have miners add an encryption key to their coinbase
transactions, then have subsequent miners mine encrypted addr messages
to single other block sources to automatically weave a miner darknet
with access controlled by successful block creation. But I doubt it's
worth the complexity of bandwidth.