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 1WxgF9-0001XZ-2K for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:35:23 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.45 as permitted sender) client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f45.google.com; Received: from mail-oa0-f45.google.com ([209.85.219.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxgF7-0003OD-Aj for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:35:23 +0000 Received: by mail-oa0-f45.google.com with SMTP id o6so5863451oag.4 for ; Thu, 19 Jun 2014 10:35:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.79.102 with SMTP id i6mr3519325obx.85.1403199315804; Thu, 19 Jun 2014 10:35:15 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Thu, 19 Jun 2014 10:35:15 -0700 (PDT) In-Reply-To: <53A31B3E.7020906@monetize.io> References: <53A316BE.5040508@certimix.com> <53A31B3E.7020906@monetize.io> Date: Thu, 19 Jun 2014 19:35:15 +0200 X-Google-Sender-Auth: PQxD45TpYLneHg6fd_Yw4xBtg2c Message-ID: From: Mike Hearn To: Mark Friedenbach Content-Type: multipart/alternative; boundary=047d7b2e46d2c48ae504fc33ccb1 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 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: 1WxgF7-0003OD-Aj Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance: 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: Thu, 19 Jun 2014 17:35:23 -0000 --047d7b2e46d2c48ae504fc33ccb1 Content-Type: text/plain; charset=UTF-8 > > The issue is centralized transaction selection policies, which is > entirely orthogonal. And the solution already exists: getblocktemplate. My (fresh!) understanding is that the reason we don't see people using getblocktemplate to decentralise pools is because libblkmaker and other implementations don't actually support connecting your own node to the miners and choosing your own blocks, even though the protocol does. I've written up a blog post that I hope will go out on the Foundation blog soon with some low hanging fruity ideas for miner decentralisation. Sergio, I'd love to give you intelligent feedback but unfortunately reading it made my brain explode :) Sorry! --047d7b2e46d2c48ae504fc33ccb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The issue is centralized transaction selection p= olicies, which is
entirely orthogonal. And the solution already exists: getblocktemplate.

My (fresh!) understanding is that the reason w= e don't see people using getblocktemplate to decentralise pools is beca= use libblkmaker and other implementations don't actually support connec= ting your own node to the miners and choosing your own blocks, even though = the protocol does.

I've written up a blog post that I hope will go out= on the Foundation blog soon with some low hanging fruity ideas for miner d= ecentralisation.

Sergio, I'd love to give you = intelligent feedback but unfortunately reading it made my brain explode :) = Sorry!
--047d7b2e46d2c48ae504fc33ccb1--