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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kevinsisco61784@gmail.com>) id 1WxfsU-0006h4-UO
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 17:11:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175;
envelope-from=kevinsisco61784@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WxfsT-0007u1-B3
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jun 2014 17:11:58 +0000
Received: by mail-qc0-f175.google.com with SMTP id i8so2419660qcq.6
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Jun 2014 10:11:51 -0700 (PDT)
X-Received: by 10.224.166.73 with SMTP id l9mr9168508qay.34.1403197911701;
Thu, 19 Jun 2014 10:11:51 -0700 (PDT)
Received: from [192.168.1.115] (ool-43521013.dyn.optonline.net. [67.82.16.19])
by mx.google.com with ESMTPSA id
w105sm3576702qgd.22.2014.06.19.10.11.49
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 19 Jun 2014 10:11:50 -0700 (PDT)
Message-ID: <53A319D0.9080309@gmail.com>
Date: Thu, 19 Jun 2014 13:11:44 -0400
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <53A316BE.5040508@certimix.com>
In-Reply-To: <53A316BE.5040508@certimix.com>
Content-Type: multipart/alternative;
boundary="------------060008080309090609070701"
X-Spam-Score: -0.3 (/)
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
(kevinsisco61784[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (kevinsisco61784[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WxfsT-0007u1-B3
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 17:11:59 -0000
This is a multi-part message in MIME format.
--------------060008080309090609070701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 6/19/2014 12:58 PM, Sergio Lerner wrote:
>
> I propose a setting that prevent mining pools AND reduce payoff
> variance which requires two changes: increasing the block-rate and
> changing the Bitcoin PoW (but still allowing current Bitcoin ASICs to
> work (as far as I know)). The block rate must be increased at least 20
> times and block must still be near full (e.g. there must be at least
> 20 more transactions/second than there is today)
>
> BlockPow is kind of PoW that only practically prevents mining pools
> for certain cryptocurrency settings based on concepts similar to
> parmacoin, but in a much simple degree. The idea is that if miners try
> to join a pool, then they incur in overhead of transmitting
> information and earn less than working solo. Let b (the payload)
> contain a full block. b must contain all the transactions and the
> header, and not only the transaction hashes. b should not hide
> anything. Let h be the block header (which contains the previous block
> hash and the Merkle tree root of the transactions). Let d be the
> difficulty. hash-block-length(b) returns the number of blocks
> processed by the hash function when fed with the block b. The target
> is divided by hash-block-length(b) so that the difficulty does not
> depend on the length of the block. Some other function can be used to
> encourage nodes to add more or less transactions.
>
> Def: Basic BlockPoW concept
>
> For each r in the nonce-range: if H ( H( r || b ) || h || r) ) < 2^-d/
> hash-block-length(b) then return r
>
> return null
>
> The header (h) is appended to the hashed message to allow SPV clients
> to verify the PoW without requiring the full block to be downloaded.
> Peers can send only (x,r,h) to SPV nodes, where x = H( r || b ), so
> they can verify the PoW. The verification procedure is obvious, and is
> skipped here. r is inserted at the beginning of the message to prevent
> pool administrators from keeping a secret mid-state of the hash
> function secret in order to prevent block stealing and also to force
> the miner to know b in the inner mining loop.
>
> So now mining requires the knowledge of the block b to be mined, and b
> must be received at each block-chain epoch. This could create an
> incentive not to include any transaction and use an almost empty b,
> because that way the bandwidth requirements is decreased. But this
> incentive should not exists normally, since by including transactions
> the solo miner gets an additional revenue from fees, which is lost if
> the block is empty. Anyway, to prevent this possible incentive we can
> append to b a subset of previous blocks (e.g 100 blocks). The block
> subset to include could be derived from a peudo-random function seeded
> by the previous block hash. Then a node would still need to download
> part or all the block-chain in order to mine.
>
> Now if the miner wants to be a dumb node and take part of a pool, then
> the current working unsolved block (the template) must be sent each
> time from the pool admin to each miner. If the pool admin hosts 1000
> miners, then to serve them with fresh block templates he needs 1000
> times more bandwidth that the miners, making this much more expensive.
> If miners create another network topology to distribute templates,
> they are incurring in the same overhead as being actively part of the
> cryptocurrency network, so they gain nothing.
>
> For example, in a block-chain with a 5 seconds block-rate, such as in
> NimbleCoin <http://nimbleCoin.org>, each block can be as large as 200
> Kbytes (100 tps are allowed). A miner will require the block template
> to be ready as fast as possible, say before 3 seconds, so as not to
> loose more than 60% of the times the transaction fees present in the
> block template. This means that a pool admin serving 1000 clients must
> have a upload bandwidth of at least 60 Mbytes/sec, and load balance
> servers, because all miners will demand the block template at the same
> time and will compete for it.
>
> The same miner, working solo, will not loose the 60% of block fees. If
> block fees are 10% of block reward, then solo miners earn 6% more than
> pool miners. Also, having a block rate of 5 seconds allows solo miners
> to receive payments more often and so it reduces the payment variance.
>
> This method to discourage mining pools only work as long as time is
> takes to transmit a block is comparable to the block interval time,
> e.g. 20%. This seems not to be a problem since if the cryptocurrency
> becomes popular, then we can expect blocks to be near full, while if
> is is not, then nobody will care about mining pools.
>
> For this method to work for Bitcoin, Bitcoin should reduce the block
> rate to at least 1 minute, and keep blocks of at least 10 Mbytes. Or
> go the NimbleCoin way, and reduce the block interval to 5 seconds. The
> sole reduction of the block rate from 10 minutes to 5 seconds would
> reduce notably the mining reward variance, which is the main reason
> miners don't mine solo.
>
> BitcoinBlockPow
>
> The basic BlockPoW is incompatible with Bitcoin ASICs as is but it can
> be made partially compatible with some tweaks: The value b is replaced
> by a a a subset or an integrity check of the block.
>
> Using a subset:
>
> First the hashMerkleRoot and hashPrevBlock fields are replaced by the
> fields: ChildBlock (32 bytes) and ScatteredBlockBytes (32 bytes).
> ChildBlock is the hash of a message with stores the old hashMerkleRoot
> and hashPrevBlock. ScatteredBlockBytes is a pseudo-random subset of
> bytes taken from the block template being mined. The seed for the
> pseudo-random function that selects the subset is the hashMerkleRoot
> plus the block time. When a miner scans all the 32bit nonce space,
> then a new hashMerkleRoot must be created to increase the extra-nonce
> field or the time must be updated. When this happens, a new subset of
> pseudo-random 32 block bytes must be collected. If the miner only
> stores 10% of the block template (e.g. 100 Kbytes instead of 1 Mbyte),
> then the probability he can build the ScatteredBlockBytes by
> brute-forcing the seed is 10^-32. If the miner performs 100 GH/sec,
> then the 32-bit nonce will overflow every 20 msec and the miner could
> request the ScatteredBlockBytes from the pool admin using a bandwidth
> of 1 Kbyte/s. A pool hosting 6 PH/sec (such as Eligious, which has 8%)
> would need to stream more than 60 Mb/s of ScatteredBlockBytes fields.
> A mining pool having 50% would need to stream 500 Mb/s, which is quite
> challenging. So miners will download the block normally, and become
> active part of the network.
>
> Using an integrity check:
>
> ScatteredBlockBytes is replaced by a field BlockHash defined as H(
> full-block-with-zero-nonce ). Obviously the header must be at the
> beginning of the block to force the re-hash.
>
> Best regards,
> Sergio.
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Why do you want to punish pools?
--
Kevin
--------------060008080309090609070701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/19/2014 12:58 PM, Sergio Lerner
wrote:<br>
</div>
<blockquote cite="mid:53A316BE.5040508@certimix.com" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<p>I propose a setting that prevent mining pools AND reduce payoff
variance which requires two changes: increasing the block-rate
and changing the Bitcoin PoW (but still allowing current Bitcoin
ASICs to work (as far as I know)). The block rate must be
increased at least 20 times and block must still be near full
(e.g. there must be at least 20 more transactions/second than
there is today)<br>
</p>
<p>BlockPow is kind of PoW that only practically prevents mining
pools for certain cryptocurrency settings based on concepts
similar to parmacoin, but in a much simple degree. The idea is
that if miners try to join a pool, then they incur in overhead
of transmitting information and earn less than working solo. Let
b (the payload) contain a full block. b must contain all the
transactions and the header, and not only the transaction
hashes. b should not hide anything. Let h be the block header
(which contains the previous block hash and the Merkle tree root
of the transactions). Let d be the difficulty.
hash-block-length(b) returns the number of blocks processed by
the hash function when fed with the block b. The target is
divided by hash-block-length(b) so that the difficulty does not
depend on the length of the block. Some other function can be
used to encourage nodes to add more or less transactions.</p>
<p><span data-mce-style="text-decoration: underline;">Def</span>:
Basic BlockPoW concept<br>
</p>
<p>For each r in the nonce-range: if H ( H( r || b ) || h || r) )
< 2^-d/ hash-block-length(b) then return r</p>
<p>return null</p>
<p>The header (h) is appended to the hashed message to allow SPV
clients to verify the PoW without requiring the full block to be
downloaded. Peers can send only (x,r,h) to SPV nodes, where x =
H( r || b ), so they can verify the PoW. The verification
procedure is obvious, and is skipped here. r is inserted at the
beginning of the message to prevent pool administrators from
keeping a secret mid-state of the hash function secret in order
to prevent block stealing and also to force the miner to know b
in the inner mining loop.</p>
<p>So now mining requires the knowledge of the block b to be
mined, and b must be received at each block-chain epoch. This
could create an incentive not to include any transaction and use
an almost empty b, because that way the bandwidth requirements
is decreased. But this incentive should not exists normally,
since by including transactions the solo miner gets an
additional revenue from fees, which is lost if the block is
empty. Anyway, to prevent this possible incentive we can append
to b a subset of previous blocks (e.g 100 blocks). The block
subset to include could be derived from a peudo-random function
seeded by the previous block hash. Then a node would still need
to download part or all the block-chain in order to mine.</p>
<p>Now if the miner wants to be a dumb node and take part of a
pool, then the current working unsolved block (the template)
must be sent each time from the pool admin to each miner. If the
pool admin hosts 1000 miners, then to serve them with fresh
block templates he needs 1000 times more bandwidth that the
miners, making this much more expensive. If miners create
another network topology to distribute templates, they are
incurring in the same overhead as being actively part of the
cryptocurrency network, so they gain nothing.</p>
<p>For example, in a block-chain with a 5 seconds block-rate, such
as in <a moz-do-not-send="true" href="http://nimbleCoin.org"
data-mce-href="http://nimbleCoin.org">NimbleCoin</a>, each
block can be as large as 200 Kbytes (100 tps are allowed). A
miner will require the block template to be ready as fast as
possible, say before 3 seconds, so as not to loose more than 60%
of the times the transaction fees present in the block template.
This means that a pool admin serving 1000 clients must have a
upload bandwidth of at least 60 Mbytes/sec, and load balance
servers, because all miners will demand the block template at
the same time and will compete for it.</p>
<p>The same miner, working solo, will not loose the 60% of block
fees. If block fees are 10% of block reward, then solo miners
earn 6% more than pool miners. Also, having a block rate of 5
seconds allows solo miners to receive payments more often and so
it reduces the payment variance.</p>
<p>This method to discourage mining pools only work as long as
time is takes to transmit a block is comparable to the block
interval time, e.g. 20%. This seems not to be a problem since if
the cryptocurrency becomes popular, then we can expect blocks to
be near full, while if is is not, then nobody will care about
mining pools.</p>
<p>For this method to work for Bitcoin, Bitcoin should reduce the
block rate to at least 1 minute, and keep blocks of at least 10
Mbytes. Or go the NimbleCoin way, and reduce the block interval
to 5 seconds. The sole reduction of the block rate from 10
minutes to 5 seconds would reduce notably the mining reward
variance, which is the main reason miners don't mine solo.<br>
</p>
<p>BitcoinBlockPow<br>
</p>
<p>The basic BlockPoW is incompatible with Bitcoin ASICs as is but
it can be made partially compatible with some tweaks: The value
b is replaced by a a a subset or an integrity check of the
block.</p>
<p>Using a subset: <br>
</p>
<p>First the hashMerkleRoot and hashPrevBlock fields are replaced
by the fields: ChildBlock (32 bytes) and ScatteredBlockBytes (32
bytes). ChildBlock is the hash of a message with stores the old
hashMerkleRoot and hashPrevBlock. ScatteredBlockBytes is a
pseudo-random subset of bytes taken from the block template
being mined. The seed for the pseudo-random function that
selects the subset is the hashMerkleRoot plus the block time.
When a miner scans all the 32bit nonce space, then a new
hashMerkleRoot must be created to increase the extra-nonce field
or the time must be updated. When this happens, a new subset of
pseudo-random 32 block bytes must be collected. If the miner
only stores 10% of the block template (e.g. 100 Kbytes instead
of 1 Mbyte), then the probability he can build the
ScatteredBlockBytes by brute-forcing the seed is 10^-32. If the
miner performs 100 GH/sec, then the 32-bit nonce will overflow
every 20 msec and the miner could request the
ScatteredBlockBytes from the pool admin using a bandwidth of 1
Kbyte/s. A pool hosting 6 PH/sec (such as Eligious, which has
8%) would need to stream more than 60 Mb/s of
ScatteredBlockBytes fields. A mining pool having 50% would need
to stream 500 Mb/s, which is quite challenging. So miners will
download the block normally, and become active part of the
network.<br>
</p>
<p>Using an integrity check:<br>
</p>
<p>ScatteredBlockBytes is replaced by a field BlockHash defined
as H( full-block-with-zero-nonce ). Obviously the header must be
at the beginning of the block to force the re-hash.<br>
</p>
<p>Best regards,<br>
Sergio.<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/hpccsystems">http://p.sf.net/sfu/hpccsystems</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
Why do you want to punish pools?<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Kevin
</pre>
</body>
</html>
--------------060008080309090609070701--
|