blob: e7472033272afc968547ba05a099e8b7e3782bbd (
plain)
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
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thyshizzle@outlook.com>) id 1YriB8-0005tW-DL
for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 07:31:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of outlook.com
designates 65.54.190.19 as permitted sender)
client-ip=65.54.190.19; envelope-from=thyshizzle@outlook.com;
helo=BAY004-OMC1S8.hotmail.com;
Received: from bay004-omc1s8.hotmail.com ([65.54.190.19])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YriB4-0004ZZ-DN
for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 07:31:06 +0000
Received: from BAY403-EAS18 ([65.54.190.60]) by BAY004-OMC1S8.hotmail.com over
TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
Mon, 11 May 2015 00:30:56 -0700
X-TMN: [Q8JGsQJxDLDQZFsxXxRPaDIhdXeJqSjt]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <BAY403-EAS184981B0219DEB969D407CC2DB0@phx.gbl>
Content-Type: multipart/alternative;
boundary="_327cf9e6-a149-4fe6-9ac8-f6cda3e0b790_"
MIME-Version: 1.0
To: Sergio Lerner <sergiolerner@certimix.com>,
"bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
From: Thy Shizzle <thyshizzle@outlook.com>
Date: Mon, 11 May 2015 17:30:49 +1000
X-OriginalArrivalTime: 11 May 2015 07:30:56.0669 (UTC)
FILETIME=[6B750CD0:01D08BBC]
X-Spam-Score: -0.5 (/)
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
(thyshizzle[at]outlook.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.54.190.19 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YriB4-0004ZZ-DN
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
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: Mon, 11 May 2015 07:31:06 -0000
--_327cf9e6-a149-4fe6-9ac8-f6cda3e0b790_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Yes This!
So many people seem hung up on growing the block size! If gaining a higher =
tps throughput is the main aim=2C I think that this proposition to speed up=
block creation has merit!
Yes it will lead to an increase in the block chain still due to 1mb ~1 minu=
te instead of ~10 minute=2C but the change to the protocol is minor=2C you =
are only adding in a different difficulty rate starting from hight blah=2C =
no new features or anything are being added so there seems to me much less =
of a security risk! Also that impact if a hard fork should be minimal becau=
se there is nothing but absolute incentive for miners to mine at the new ea=
sier difficulty!
I feel this deserves a great deal of consideration as opposed to blowing ou=
t the block through miners voting etc!!!!
________________________________
From: Sergio Lerner<mailto:sergiolerner@certimix.com>
Sent: =E2=80=8E11/=E2=80=8E05/=E2=80=8E2015 5:05 PM
To: bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@li=
sts.sourceforge.net>
Subject: [Bitcoin-development] Reducing the block rate instead of increasin=
g the maximum block size
In this e-mail I'll do my best to argue than if you accept that
increasing the transactions/second is a good direction to go=2C then
increasing the maximum block size is not the best way to do it. I argue
that the right direction to go is to decrease the block rate to 1
minute=2C while keeping the block size limit to 1 Megabyte (or increasing
it from a lower value such as 100 Kbyte and then have a step function).
I'm backing up my claims with many hours of research simulating the
Bitcoin network under different conditions [1]. I'll try to convince
you by responding to each of the arguments I've heard against it.
Arguments against reducing the block interval
1. It will encourage centralization=2C because participants of mining
pools will loose more money because of excessive initial block template
latency=2C which leads to higher stale shares
When a new block is solved=2C that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes=2C
then a new block header candidate is created=2C and this header must be
propagated to all the mining pool users=2C ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around=2C the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients=2C then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources=2C so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth=2C but I guess the investment would be l=
ow.
2. It will increase the probability of a block-chain split
The convergence of the network relies on the diminishing probability of
two honest miners creating simultaneous competing blocks chains. To
increase the competition chain=2C competing blocks must be generated in
almost simultaneously (in the same time window approximately bounded by
the network average block propagation delay). The probability of a block
competition decreases exponentially with the number of blocks. In fact=2C
the probability of a sustained competition on ten 1-minute blocks is one
million times lower than the probability of a competition of one
10-minute block. So even if the competition probability of six 1-minute
blocks is higher than of six ten-minute blocks=2C this does not imply
reducing the block rate increases this chance=2C but on the contrary=2C
reduces it.
3=2C It will reduce the security of the network
The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.
A still holds. B holds for the same amount of confirmation blocks=2C so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes=2C as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However=2C there is no shop where
one can find 51% of the hashing power to rent right now=2C nor probably
will ever be if Bitcoin succeeds. Last=2C you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments=2C
so the security decreases only if participant wish to decrease it.
4. Reducing the block propagation time on the average case is good=2C but
what happen in the worse case?
Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners=2C
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network=2C but not more. In other words=2C to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice=2C and surely doomed to fail=2C as network conditions dynamically
change. Also it would be perceived as an attack to the network=2C and the
miner (if it is a public mining pool) would be probably blacklisted.
5. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016=2C then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages=2C bitcointalk=2C SPV wallets warnings=2C coindesk=2C one year in
advance will give plenty of time to SPV wallet users to upgrade.
6. If there are 10x more blocks=2C then there are 10x more block headers=2C
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3]=2C so if synchronization were
to be done only at night when the phone is connected to the power line=2C
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment=2C and the smart-phone is 1 day
out-of-synch=2C then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher=2C
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
According to CISCO mobile bandwidth connection speed increases 20% every
year. In four years=2C it will have doubled=2C so mobile phones with lower
than average data connection will soon be able to catchup.
Also there is low-hanging-fruit optimizations to the protocol that have
not been implemented: each header is 80 bytes in length. When a set of
chained headers is transferred=2C the headers could be compressed=2C
stripping 32 bytes of each header that is derived from the previous
header hash digest. So a 40% compression is already possible by slightly
modifying the wire protocol.
7. There has been insufficient testing and/or insufficient research into
technical/economic implications or reducing the block rate
This is partially true. in the GHOST paper=2C this has been analyzed=2C and
the problem was shown to be solvable for block intervals of just a few
seconds. There are several proof-of-work cryptocurrencies in existence
that have lower than 1 minute block intervals and they work just fine.
First there was Bitcoin with a 10 minute interval=2C then was LiteCoin
using a 2.5 interval=2C then was DogeCoin with 1 minute=2C and then
QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a
little bit. Some time ago I decided to research on the block rate to
understand how the block interval impacts the stability and capability
of the cryptocurrency network=2C and I came up with the idea of the DECOR+
protocol [4] (which requires changes in the consensus code). In my
research I also showed how the stale rate can be easily reduced only
with changes in the networking code=2C and not in the consensus code.
These networking optimizations ( O(1) propagation using headers-first or
IBLTs)=2C can be added later.
Mortifying Bitcoin to accommodate the change to lower the block rate
requires at least:
- Changing the 21 BTC reward per block to 2.1 BTC
- Changing the nPowTargetTimespan constant
- Writing code to hard-fork automatically when the majority of miners
have upgraded.
- Allow transaction version 3=2C and interpret nLockTimes of transaction
version 2 as being multiplied by 10.
All changes comprises no more than 15 lines of code. This is much less
than the number of lines modified by Gavin's 20Mb patch.
As a conclusion=2C I haven't yet heard a good argument against lowering
the block rate.
Best regards=2C
Sergio.
[0] https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
[1] https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
[2] http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
[3]
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-n=
etworking-index-vni/white_paper_c11-520862.html
[4] https://bitslog.wordpress.com/2014/05/02/decor/
---------------------------------------------------------------------------=
---
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics=2C stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--_327cf9e6-a149-4fe6-9ac8-f6cda3e0b790_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">Yes =
This!<br>
<br>
So many people seem hung up on growing the block size! If gaining a higher =
tps throughput is the main aim=2C I think that this proposition to speed up=
block creation has merit!<br>
<br>
Yes it will lead to an increase in the block chain still due to 1mb ~1 minu=
te instead of ~10 minute=2C but the change to the protocol is minor=2C you =
are only adding in a different difficulty rate starting from hight blah=2C =
no new features or anything are being
added so there seems to me much less of a security risk! Also that impact =
if a hard fork should be minimal because there is nothing but absolute ince=
ntive for miners to mine at the new easier difficulty!<br>
<br>
I feel this deserves a great deal of consideration as opposed to blowing ou=
t the block through miners voting etc!!!!</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:sergiolerner@certimix.com">Sergio Lerner</a></span><=
br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E11/=E2=80=8E05/=E2=80=8E2015 5:05 PM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-d=
evelopment@lists.sourceforge.net</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">[Bitcoin-development] Reducing the block rate instead of increasing th=
e maximum block size</span><br>
<br>
</div>
<div class=3D"BodyFragment">
<div class=3D"PlainText">In this e-mail I'll do my best to argue than if yo=
u accept that<br>
increasing the transactions/second is a good direction to go=2C then<br>
increasing the maximum block size is not the best way to do it. I argue<br>
that the right direction to go is to decrease the block rate to 1<br>
minute=2C while keeping the block size limit to 1 Megabyte (or increasing<b=
r>
it from a lower value such as 100 Kbyte and then have a step function).<br>
I'm backing up my claims with many hours of research simulating the<br>
Bitcoin network under different conditions [1]. =3B I'll try to convinc=
e<br>
you by responding to each of the arguments I've heard against it.<br>
<br>
Arguments against reducing the block interval<br>
<br>
1. It will encourage centralization=2C because participants of mining<br>
pools will loose more money because of excessive initial block template<br>
latency=2C which leads to higher stale shares<br>
<br>
When a new block is solved=2C that information needs to propagate<br>
throughout the Bitcoin network up to the mining pool operator nodes=2C<br>
then a new block header candidate is created=2C and this header must be<br>
propagated to all the mining pool users=2C ether by a push or a pull<br>
model. Generally the mining server pushes new work units to the<br>
individual miners. If done other way around=2C the server would need to<br>
handle a high load of continuous work requests that would be difficult<br>
to distinguish from a DDoS attack. So if the server pushes new block<br>
header candidates to clients=2C then the problem boils down to increasing<b=
r>
bandwidth of the servers to achieve a tenfold increase in work<br>
distribution. Or distributing the servers geographically to achieve a<br>
lower latency. Propagating blocks does not require additional CPU<br>
resources=2C so mining pools administrators would need to increase<br>
moderately their investment in the server infrastructure to achieve<br>
lower latency and higher bandwidth=2C but I guess the investment would be l=
ow.<br>
<br>
2. It will increase the probability of a block-chain split<br>
<br>
The convergence of the network relies on the diminishing probability of<br>
two honest miners creating simultaneous competing blocks chains. To<br>
increase the competition chain=2C competing blocks must be generated in<br>
almost simultaneously (in the same time window approximately bounded by<br>
the network average block propagation delay). The probability of a block<br=
>
competition decreases exponentially with the number of blocks. In fact=2C<b=
r>
the probability of a sustained competition on ten 1-minute blocks is one<br=
>
million times lower than the probability of a competition of one<br>
10-minute block. So even if the competition probability of six 1-minute<br>
blocks is higher than of six ten-minute blocks=2C this does not imply<br>
reducing the block rate increases this chance=2C but on the contrary=2C <br=
>
reduces it.<br>
<br>
3=2C It will reduce the security of the network<br>
<br>
The security of the network is based on two facts:<br>
A- The miners are incentivized to extend the best chain<br>
B- The probability of a reversal based on a long block competition<br>
decreases as more confirmation blocks are appended.<br>
C- Renting or buying hardware to perform a 51% attack is costly.<br>
<br>
A still holds. B holds for the same amount of confirmation blocks=2C so 6<b=
r>
confirmation blocks in a 10-minute block-chain is approximately<br>
equivalent to 6 confirmation blocks in a 1-minute block-chain.<br>
Only C changes=2C as renting the hashing power for 6 minutes is ten times<b=
r>
less expensive as renting it for 1 hour. However=2C there is no shop where<=
br>
one can find 51% of the hashing power to rent right now=2C nor probably<br>
will ever be if Bitcoin succeeds. Last=2C you can still have a 1 hour<br>
confirmation (60 1-minute blocks) if you wish for high-valued payments=2C<b=
r>
so the security decreases only if participant wish to decrease it.<br>
<br>
4. Reducing the block propagation time on the average case is good=2C but<b=
r>
what happen in the worse case?<br>
<br>
Most methods proposed to reduce the block propagation delay do it only<br>
on the average case. Any kind of block compression relies on both<br>
parties sharing some previous information. In the worse case it's true<br>
that a miner can create and try to broadcast a block that takes too much<br=
>
time to verify or bandwidth to transmit. This is currently true on the<br>
Bitcoin network. Nevertheless there is no such incentive for miners=2C<br>
since they will be shooting on their own foots. Peter Todd has argued<br>
that the best strategy for miners is actually to reach 51% of the<br>
network=2C but not more. In other words=2C to exclude the slowest 49%<br>
percent. But this strategy of creating bloated blocks is too risky in<br>
practice=2C and surely doomed to fail=2C as network conditions dynamically =
<br>
change. Also it would be perceived as an attack to the network=2C and the<b=
r>
miner (if it is a public mining pool) would be probably blacklisted.<br>
<br>
5. Thousands of SPV wallets running in mobile devices would need to be<br>
upgraded (thanks Mike).<br>
<br>
That depends on the current upgrade rate for SPV wallets like Bitcoin<br>
Wallet =3B and BreadWallet. Suppose that the upgrade rate is 80%/year: =
we<br>
develop the source code for the change now and apply the change in Q2<br>
2016=2C then =3B most of the nodes will already be upgraded by when the=
<br>
hardfork takes place. Also a public notice telling people to upgrade in<br>
web pages=2C bitcointalk=2C SPV wallets warnings=2C coindesk=2C one year in=
<br>
advance will give plenty of time to SPV wallet users to upgrade.<br>
<br>
6. If there are 10x more blocks=2C then there are 10x more block headers=2C=
<br>
and that increases the amount of bandwidth SPV wallets need to catch up<br>
with the chain<br>
 =3B<br>
A standard smartphone with average cellular downstream speed downloads<br>
2.6 headers per second (1600 kbits/sec) [3]=2C so if synchronization were<b=
r>
to be done only at night when the phone is connected to the power line=2C<b=
r>
then it would take 9 minutes to synchronize with 1440 headers/day. If a<br>
person should accept a payment=2C and the smart-phone is 1 day<br>
out-of-synch=2C then it takes less time to download all the missing<br>
headers than to wait for a 10-minute one block confirmation. Obviously<br>
all smartphones with 3G have a downstream bandwidth much higher=2C<br>
averaging 1 Mbps. So the whole synchronization will be done less than a<br>
1-minute block confirmation.<br>
 =3B<br>
According to CISCO mobile bandwidth connection speed increases 20% every<br=
>
year. In four years=2C it will have doubled=2C so mobile phones with lower<=
br>
than average data connection will soon be able to catchup.<br>
Also there is low-hanging-fruit optimizations to the protocol that have<br>
not been implemented: each header is 80 bytes in length. When a set of<br>
chained headers is transferred=2C the headers could be compressed=2C<br>
stripping 32 bytes of each header that is derived from the previous<br>
header hash digest. So a 40% compression is already possible by slightly<br=
>
modifying the wire protocol.<br>
 =3B<br>
7. There has been insufficient testing and/or insufficient research into<br=
>
technical/economic implications or reducing the block rate<br>
 =3B<br>
This is partially true. in the GHOST paper=2C this has been analyzed=2C and=
<br>
the problem was shown to be solvable for block intervals of just a few<br>
seconds. There are several proof-of-work cryptocurrencies in existence<br>
that have lower than 1 minute block intervals and they work just fine.<br>
First there was Bitcoin with a 10 minute interval=2C then was LiteCoin<br>
using a 2.5 interval=2C then was DogeCoin with 1 minute=2C and then<br>
QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a<br>
little bit. Some time ago I decided to research on the block rate to<br>
understand how the block interval impacts the stability and capability<br>
of the cryptocurrency network=2C and I came up with the idea of the DECOR&#=
43=3B<br>
protocol [4] (which requires changes in the consensus code). In my<br>
research I also showed how the stale rate can be easily reduced only<br>
with changes in the networking code=2C and not in the consensus code.<br>
These networking optimizations ( O(1) propagation using headers-first or<br=
>
IBLTs)=2C can be added later.<br>
 =3B<br>
Mortifying Bitcoin to accommodate the change to lower the block rate<br>
requires at least:<br>
 =3B<br>
- Changing the 21 BTC reward per block to 2.1 BTC<br>
- Changing the nPowTargetTimespan constant<br>
- Writing code to hard-fork automatically when the majority of miners<br>
have upgraded.<br>
- Allow transaction version 3=2C and interpret nLockTimes of transaction<br=
>
version 2 as being multiplied by 10.<br>
<br>
All changes comprises no more than 15 lines of code. This is much less<br>
than the number of lines modified by Gavin's 20Mb patch.<br>
 =3B<br>
As a conclusion=2C I haven't yet heard a good argument against lowering<br>
the block rate.<br>
<br>
Best regards=2C<br>
 =3BSergio.<br>
 =3B<br>
[0] <a href=3D"https://medium.com/@octskyward/the-capacity-cliff-586d1bf771=
5e">https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e</a><br>
[1] <a href=3D"https://bitslog.wordpress.com/2014/02/17/5-sec-block-interva=
l/">https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/</a><br>
[2] <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">h=
ttp://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><br>
[3]<br>
<a href=3D"http://www.cisco.com/c/en/us/solutions/collateral/service-provid=
er/visual-networking-index-vni/white_paper_c11-520862.html">http://www.cisc=
o.com/c/en/us/solutions/collateral/service-provider/visual-networking-index=
-vni/white_paper_c11-520862.html</a><br>
[4] <a href=3D"https://bitslog.wordpress.com/2014/05/02/decor/">https://bit=
slog.wordpress.com/2014/05/02/decor/</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud <b=
r>
Widest out-of-the-box monitoring support with 50+=3B applications<br>
Performance metrics=2C stats and reports that give you Actionable Insights<=
br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By">htt=
p://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
Bitcoin-development@lists.sourceforge.net<br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
</div>
</body>
</html>
--_327cf9e6-a149-4fe6-9ac8-f6cda3e0b790_--
|