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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
