1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
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 <marek@palatinus.cz>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP2Lq-28NuvOJR_rS3N2TZsy13xrKubcfPBrMbP7WArcKw@mail.gmail.com>
References: <53A316BE.5040508@certimix.com> <53A31B3E.7020906@monetize.io>
<CANEZrP2Lq-28NuvOJR_rS3N2TZsy13xrKubcfPBrMbP7WArcKw@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Thu, 19 Jun 2014 22:26:41 +0200
X-Google-Sender-Auth: xYIMpseM_-pfVKH-um2lQG3l4AU
Message-ID: <CAJna-HgNnwARH2AN_LJ1LFkrWL5n4X4Lo-koW0WdOWw1RUiGJA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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
--047d7b6728869db58304fc363346
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jun 19, 2014 at 7:35 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>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.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>>=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">It's part of a general trend wherein people look at all the=
things</span></div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">that can be accomplished in an economy that has a division of labor*,<=
/span><br style=3D"font-family:arial,sans-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">and see some mi=
sbehavior at the edges, and decide that rather than</span><br style=3D"font=
-family:arial,sans-serif;font-size:13px"><span style=3D"font-family:arial,s=
ans-serif;font-size:13px">fixing the misbehavior we should throw out the en=
tire concept of labor</span><br style=3D"font-family:arial,sans-serif;font-=
size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">specialization.=
</span></div><div class=3D"gmail_quote"><font face=3D"arial, sans-serif"><b=
r></font></div><div class=3D"gmail_quote"><font face=3D"arial, sans-serif">=
Well written! This reminds me - what about Stratum + SPV validation on mine=
r side?</font></div>
<div class=3D"gmail_quote"><font face=3D"arial, sans-serif"><br></font></di=
v><div class=3D"gmail_quote"><font face=3D"arial, sans-serif">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).</font></div>
<div class=3D"gmail_quote"><font face=3D"arial, sans-serif"><br></font></di=
v><div class=3D"gmail_quote"><font face=3D"arial, sans-serif">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.</font></div>
<div class=3D"gmail_quote"><font face=3D"arial, sans-serif"><br></font></di=
v><div class=3D"gmail_quote"><div>slush</div></div></div></div>
--047d7b6728869db58304fc363346--
|
