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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdIIm-0000ym-Un for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 11:26:37 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.182 as permitted sender) client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f182.google.com; Received: from mail-ob0-f182.google.com ([209.85.214.182]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdIIl-0003Yq-Tx for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 11:26:36 +0000 Received: by mail-ob0-f182.google.com with SMTP id wn1so6906099obc.41 for ; Mon, 04 Nov 2013 03:26:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.22.33 with SMTP id a1mr232321obf.60.1383564390562; Mon, 04 Nov 2013 03:26:30 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 03:26:30 -0800 (PST) Date: Mon, 4 Nov 2013 12:26:30 +0100 X-Google-Sender-Auth: LPCsa2OTMBs6yD37im-G_XrjIes Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1133177c0605cf04ea5830bb X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -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: arxiv.org] 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1VdIIl-0003Yq-Tx Subject: [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:26:37 -0000 --001a1133177c0605cf04ea5830bb Content-Type: text/plain; charset=UTF-8 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? 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. --001a1133177c0605cf04ea5830bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W.R.T. this paper and the oft-discussed miner backbone,

I&= #39;m wondering about an alternative protocol change that perhaps has less = subtle implications than their suggested change. Rather than address the pr= oblem 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 automat= ically build a miner backbone by having IP addresses of nodes embedded into= coinbases, then having any bitcoind that is creating work automatically co= nnect to IPs that appeared in enough recent blocks?=C2=A0

This would have the effect of automatically linking all= the major pools together, with no administration overhead.

<= /div>
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 re= ached 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 pro= posed by the paper.
--001a1133177c0605cf04ea5830bb--