From: slush <slush@centrum•cz>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
Date: Thu, 19 Jun 2014 22:26:41 +0200 [thread overview]
Message-ID: <CAJna-HgNnwARH2AN_LJ1LFkrWL5n4X4Lo-koW0WdOWw1RUiGJA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2Lq-28NuvOJR_rS3N2TZsy13xrKubcfPBrMbP7WArcKw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]
On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn <mike@plan99•net> 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
[-- Attachment #2: Type: text/html, Size: 3710 bytes --]
next prev parent reply other threads:[~2014-06-19 20:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 16:58 Sergio Lerner
2014-06-19 17:11 ` Kevin
2014-06-19 17:37 ` Justus Ranvier
2014-06-19 17:17 ` Mark Friedenbach
2014-06-19 17:35 ` Mike Hearn
2014-06-19 20:26 ` slush [this message]
2014-06-19 20:39 ` Mark Friedenbach
2014-06-19 20:55 ` slush
2014-06-19 21:07 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJna-HgNnwARH2AN_LJ1LFkrWL5n4X4Lo-koW0WdOWw1RUiGJA@mail.gmail.com \
--to=slush@centrum$(echo .)cz \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox