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 1WxjLx-00073V-96 for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 20:54:37 +0000 X-ACL-Warn: Received: from mail-vc0-f178.google.com ([209.85.220.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxjLv-0002bG-GS for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 20:54:37 +0000 Received: by mail-vc0-f178.google.com with SMTP id ij19so2737537vcb.37 for ; Thu, 19 Jun 2014 13:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=8XQ6O6APCzjX3pSJJuGjdq0M6R6CxOn5zBB/mTrq91w=; b=ZD6CJHlb9pFOgUMh2gkIxONNXnmvSk5cwNDHO3YSh65QuM8C+8DvwT5ttykfdn7xpK tZKQt+Rq39xrJlDPEpWUDuLXVs53jKKGYQwh48bgnYDZD4As/+p7sRqKs8GoV/izj/7r aiRfq1tQGO7JyENNk9HeKy/Q7XOz+Jp8VtqdZaelaMd/5EzPbjp0qDg4NwLkWFO1dE+X sgcs/shhadRiUgC/2DFvoeXGW+A95PrJC4xxrGoTbYpq7PuwV5fjNtBjLaxvKoFmdre0 3Ip5zM3Avka5qdIQEu3pdCCBLnJ6WzEtlZFCbk1/u6UtFZTVdzeEb9ODxMEMeyVU7ZJa U6Jw== X-Gm-Message-State: ALoCoQlZquQi8qrs3waZSOHUDiExTu4FmZlRpcg8qhEx8Pl7XB2H9dsL50Ei8LTrCljNKgKijrf0 X-Received: by 10.58.162.10 with SMTP id xw10mr1086769veb.25.1403209631243; Thu, 19 Jun 2014 13:27:11 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.218.36 with HTTP; Thu, 19 Jun 2014 13:26:41 -0700 (PDT) In-Reply-To: References: <53A316BE.5040508@certimix.com> <53A31B3E.7020906@monetize.io> From: slush Date: Thu, 19 Jun 2014 22:26:41 +0200 X-Google-Sender-Auth: xYIMpseM_-pfVKH-um2lQG3l4AU Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7b6728869db58304fc363346 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WxjLv-0002bG-GS 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 20:54:37 -0000 --047d7b6728869db58304fc363346 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn wrote: > > 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. > > Well, I don't want to start flamewar (and this topic has potential!), but the *real* reason why there isn't such infrastructure is that although GBT as a protocol *does* support of decentralized building of blocks, it is *extremely* resource consuming to validate these shares on pool side. With GBT, simply hashing the block header is not enough, because pool cannot rely on anything provided by the client. Its not only about things like withdrawal attacks, but more about hidden bugs in various miners. It is extremely hard to do full validation for *every* of submitted shares. Although I see benefits of GBT and I see limits of Stratum, I don't think that supporting full GBT validation have economic sense for any medium sized pool, because such pool would need multiply his running costs on servers many times. > It's part of a general trend wherein people look at all the things that can be accomplished in an economy that has a division of labor*, and see some misbehavior at the edges, and decide that rather than fixing the misbehavior we should throw out the entire concept of labor specialization. Well written! This reminds me - what about Stratum + SPV validation on miner side? With SPV, miner cannot choose his own transactions, so it is not fully decentralized, but at least miner can detect (in real time) two major pool misbehaviours - selfish mining (building private blockchain) and chain forking (not working on longest known blockchain). I read such proposal about Stratum + SPV on reddit and I actually like it; It removes major drawbacks of "centralized" Stratum mining, yet is gives tools to miners to instantly switch to fallback pool when something wrong is happening. slush --047d7b6728869db58304fc363346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 19, 2014 at 7:35 PM, Mike Hearn <mike@plan99.net> wrot= e:
My (fresh!) understanding is that the reason we don't see people using= getblocktemplate to decentralise pools is because libblkmaker and other im= plementations don't actually support connecting your own node to the mi= ners and choosing your own blocks, even though the protocol does.


Well, I d= on't want to start flamewar (and this topic has potential!), but the *r= eal* reason why there isn't such infrastructure is that although GBT as= a protocol *does* support of decentralized building of blocks, it is *extr= emely* resource consuming to validate these shares on pool side.

With GBT, simply hashing the block header is not enough= , because pool cannot rely on anything provided by the client. Its not only= about things like withdrawal attacks, but more about hidden bugs in variou= s miners. It is extremely hard to do full validation for *every* of submitt= ed shares.

Although I see benefits of GBT and I see limits of Stra= tum, I don't think that supporting full GBT validation have economic se= nse for any medium sized pool, because such pool would need multiply his ru= nning costs on servers many times.

>=A0It's part of a general trend wherein people look at all the= things
that can be accomplished in an economy that has a division of labor*,<= /span>
and see some mi= sbehavior at the edges, and decide that rather than
fixing the misbehavior we should throw out the en= tire concept of labor
specialization.=
= Well written! This reminds me - what about Stratum + SPV validation on mine= r side?

With SPV, min= er cannot choose his own transactions, so it is not fully decentralized, bu= t at least miner can detect (in real time) two major pool misbehaviours - s= elfish mining (building private blockchain) and chain forking (not working = on longest known blockchain).

I read such p= roposal about Stratum + SPV on reddit and I actually like it; It removes ma= jor drawbacks of "centralized" Stratum mining, yet is gives tools= to miners to instantly switch to fallback pool when something wrong is hap= pening.

slush
--047d7b6728869db58304fc363346--