Re: [Bitcoin-development] Auto-generated miner backbone

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
> 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?

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

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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]