Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdMQs-00023s-QV for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:51:14 +0000 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; Received: from mail-lb0-f176.google.com ([209.85.217.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdMQs-0008Bh-1q for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:51:14 +0000 Received: by mail-lb0-f176.google.com with SMTP id z5so5577441lbh.35 for ; Mon, 04 Nov 2013 07:51:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.202.167 with SMTP id kj7mr1531706lac.43.1383580267306; Mon, 04 Nov 2013 07:51:07 -0800 (PST) Received: by 10.112.63.164 with HTTP; Mon, 4 Nov 2013 07:51:07 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 07:51:07 -0800 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: plan99.net] X-Headers-End: 1VdMQs-0008Bh-1q Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Auto-generated miner backbone X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:51:15 -0000 On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn 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.