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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1WxjNi-00011u-BU
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 20:56:26 +0000
X-ACL-Warn:
Received: from mail-vc0-f179.google.com ([209.85.220.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WxjNg-0002eq-LI
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 20:56:26 +0000
Received: by mail-vc0-f179.google.com with SMTP id id10so2718164vcb.24
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Jun 2014 13:56:19 -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=rcr0cVjoXYA2z1cTvQwQEt3IxUmMTQWfOF/EdB7PVUI=;
b=LHXh9ZIQyUFA/8dZ616eKLazq/VTV9ynVIOh+zr7F84Fp0uNHYOj34gQ+fsOrKwkOb
mcJL/6OK1tXTcJyevtiKvuEpHCPMLTbU9G/DJCky4n/XALv+W6IVpqOXuPkpUfzmCxsa
S//RMm6zAGNwAvoxMiEEl/paseAehVaFceYAJvnHKUPEY845gBoXH4YEW/uoDvOPW7/9
X4yr4RuYLfJjWEKdzt797fPkqV6O58qNDbN5MrkbSXHuUfNWodtP1jUjCvT4E3bdAUzW
6iHr2G/9hHGMojAc9GVRrnt7t/qxyYJU2Dr8pTFu83qzkjzzT1ibZBuLqM0ueDmqFNDd
q4kA==
X-Gm-Message-State: ALoCoQng8jJJ+YYmIc3tGV//fCR+5yqSJO3k5u9o2G3K/6SQVEXMcBk4LmI/ga0VAEr7+wHaGxDv
X-Received: by 10.52.191.68 with SMTP id gw4mr40486vdc.65.1403211379035; Thu,
19 Jun 2014 13:56:19 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.218.36 with HTTP; Thu, 19 Jun 2014 13:55:48 -0700 (PDT)
In-Reply-To: <53A34A71.2090106@monetize.io>
References: <53A316BE.5040508@certimix.com> <53A31B3E.7020906@monetize.io>
<CANEZrP2Lq-28NuvOJR_rS3N2TZsy13xrKubcfPBrMbP7WArcKw@mail.gmail.com>
<CAJna-HgNnwARH2AN_LJ1LFkrWL5n4X4Lo-koW0WdOWw1RUiGJA@mail.gmail.com>
<53A34A71.2090106@monetize.io>
From: slush <slush@centrum.cz>
Date: Thu, 19 Jun 2014 22:55:48 +0200
X-Google-Sender-Auth: UnFaRVg5Jr0G-rX-iCu7kqQ3QN0
Message-ID: <CAJna-HgP=RvbFpkdwqkoNP0fmMg6r80zDKrA-Cb2mcbmyjOTEA@mail.gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: multipart/alternative; boundary=089e013a219ccb086804fc369bf7
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: 1WxjNg-0002eq-LI
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:56:26 -0000
--089e013a219ccb086804fc369bf7
Content-Type: text/plain; charset=ISO-8859-1
Miner issues are just one thing what came to my mind. What about validating
transactions? How the pool can be sure that miner is running up to date
bitcoind which do full validation of transactions? Not talking that if
every miner takes his own set of transaction, pool need to calculate merkle
root for every submit, to check its correctness.
I don't think it *cannot* be done, it is just extremely hard and there's no
economic motivation for such complication on pool side. Just see current
pools, they are full of security and stability bugs even while using such
trivial protocol like Stratum...
slush
On Thu, Jun 19, 2014 at 10:39 PM, Mark Friedenbach <mark@monetize.io> wrote:
> Do you need to do full validation? There's an economic cost to mining
> invalid blocks, and even if that were acceptable there's really no
> reason to perform such an attack. The result would be similar to a block
> withholding attack, but unlike block withholding it would be trivially
> detectable if/when full validation was performed.
>
> To protect yourself and to detect incorrect mining software you could
> stochastically validate a randomly selected sample of shares, as your
> hardware requirements allow.
>
> On 06/19/2014 01:26 PM, slush wrote:
> > 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.
>
--089e013a219ccb086804fc369bf7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Miner issues are just one thing=
what came to my mind. What about validating transactions? How the pool can=
be sure that miner is running up to date bitcoind which do full validation=
of transactions? Not talking that if every miner takes his own set of tran=
saction, pool need to calculate merkle root for every submit, to check its =
correctness.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I don't=
think it *cannot* be done, it is just extremely hard and there's no ec=
onomic motivation for such complication on pool side. Just see current pool=
s, they are full of security and stability bugs even while using such trivi=
al protocol like Stratum...</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">slush</div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jun 19, 2=
014 at 10:39 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:m=
ark@monetize.io" target=3D"_blank">mark@monetize.io</a>></span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Do you need to do full validation? There'=
;s an economic cost to mining<br>
invalid blocks, and even if that were acceptable there's really no<br>
reason to perform such an attack. The result would be similar to a block<br=
>
withholding attack, but unlike block withholding it would be trivially<br>
detectable if/when full validation was performed.<br>
<br>
To protect yourself and to detect incorrect mining software you could<br>
stochastically validate a randomly selected sample of shares, as your<br>
hardware requirements allow.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 06/19/2014 01:26 PM, slush wrote:<br>
> With GBT, simply hashing the block header is not enough, because pool<=
br>
> cannot rely on anything provided by the client. Its not only about<br>
> things like withdrawal attacks, but more about hidden bugs in various<=
br>
> miners. It is extremely hard to do full validation for *every* of<br>
> submitted shares.<br>
</div></div></blockquote></div><br></div></div>
--089e013a219ccb086804fc369bf7--
|
