From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdIin-0001H2-Fw for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 11:53:29 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.154 as permitted sender) client-ip=62.13.148.154; envelope-from=pete@petertodd.org; helo=outmail148154.authsmtp.co.uk; Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VdIim-0004y9-4x for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 11:53:29 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4BrLZs057493; Mon, 4 Nov 2013 11:53:21 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4BrFEw081380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 11:53:17 GMT Date: Mon, 4 Nov 2013 06:53:14 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20131104115314.GA1013@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: b20b14e8-4547-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgYUFloCAgsB AmUbWlVeVV57WGs7 bAxPbAVDY01GQQRq WVdMSlVNFUsqcBhz RGhrFRl6dgZOeDBx ZkRqXz4JXkQodEIo SlNQEGkBeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4iAyI7 Ah8PGzg1FFEIS202 LhorMBYWFU0SOEI0 PDMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record 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: petertodd.org] X-Headers-End: 1VdIim-0004y9-4x 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 11:53:29 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote: > W.R.T. this paper and the oft-discussed miner backbone, >=20 > http://arxiv.org/pdf/1311.0243v1.pdf >=20 > 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. >=20 > 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 v= ia > 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. >=20 > It feels like this should be achievable with a few days of solid coding a= nd > a couple of new command line flags, and the impact is much easier to reas= on > 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 ... 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. --=20 'peter'[:-1]@petertodd.org 00000000000000080e395c361bdf9db583d5f4c0e144f476c229285b15eae59c --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJSd4qqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMGE2ZGQ5NmM1NTFlY2E3Mjk5NDYzZTRlNTIzNDYyNzk4YTAw NjUzNWY0MTJiNTE5YzcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfurmQf/SQOlv6xWFDlco0Kc6PeawDJF eJ39EqKZ5rqxkIVMspJtBXrg30+aF/ZeU2fQIfRRSi5iED1exTm+y+a5trXhrm2A PUNMLBEhztemzC+7B8HOZ983Pm7YHMO57xiuDHXDjbwdRPeq0cxkLG4PqxUnzMzB jNII1PXLjpD9z9M3PAHVugcEboqiuaXgKvoP5gMMjliFrjwT14V5Ojai/tjfb4YS sZKH5xWYQlGSPZFW4Qp0TDOUuQXmo8gDlkTZHUs3q4pvri6HKEOPQv4TlUNijxhV iEwfEmy4wBk3QMEjl8M1RTMREN7r/CqsfKey9xc/fMU8ViQzBmXvN2xtZajIBw== =6FFl -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--