-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathmaxwells-scaling-roadmap.html
676 lines (544 loc) · 22.4 KB
/
maxwells-scaling-roadmap.html
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
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Greg Maxwells Roadmap for Bitcoin Scaling</title>
<meta name="description" content="Greg Maxwell made an important submission to the dev-mailing list that I wanted to repost (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decem...">
<link rel="stylesheet" href="/Daniel-Blog/assets/css/main.css">
<link rel="canonical" href="http://Daunus.github.io/Daniel-Blog/maxwells-scaling-roadmap">
<link rel="alternate" type="application/rss+xml" title="Daniel Wilczynski" href="http://Daunus.github.io/Daniel-Blog/feed.xml">
</head>
<body>
<header class="site-header container-fluid center">
<div class="site-title center">
<h1><a href="/Daniel-Blog/">Daniel Wilczynski</a></h1>
<p class="site-description">Biographical Page & Blog</p>
</div>
<div class="site-nav">
<a class="page-link button_outline" href="/Daniel-Blog/">Blog</a>
<a class="page-link button_outline" href="/Daniel-Blog/about/">About</a>
</div>
</header>
<div class = "container" >
<h1 class="post-title">
Greg Maxwells Roadmap for Bitcoin Scaling
</h1>
<div class="post-meta">
Dec 14, 2015 | 15 Min Read |
<span class="disqus-comment-count" data-disqus-identifier="Greg Maxwells Roadmap for Bitcoin Scaling"></span>
</div>
</div>
<article class="post" itemscope itemtype="http://schema.org/BlogPosting">
<div class="post-content container" itemprop="articleBody">
<p>Greg Maxwell made an important submission to the dev-mailing list that I wanted to repost (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html). It is his summary of Bitcoin protocol development and his proposal for the future direction. It has received a good response, even from the XT/Big Block crowd. The only point of contention seems to be regarding Segregated Witnesses. Greg proposes to roll this out ASAP as a soft-fork. Gavin Andresen, Jonathan Toomim (XT Developer) and Mark Friedenbach seem to be of the opinion it should be a hard-fork. I have included some responses towards the end.</p>
<p>Greg Maxwell:</p>
<blockquote>
<blockquote>
<p>The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating
proposals were presented. I think this would be a good time to share my
view of the near term arc for capacity increases in the Bitcoin system. I
believe we’re in a fantastic place right now and that the community
is ready to deliver on a clear forward path with a shared vision that
addresses the needs of the system while upholding its values.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>I think it’s important to first clearly express some of the relevant
principles that I think should guide the ongoing development of the
Bitcoin system.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Bitcoin is P2P electronic cash that is valuable over legacy systems
because of the monetary autonomy it brings to its users through
decentralization. Bitcoin seeks to address the root problem with
conventional currency: all the trust that’s required to make it work–</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>— Not that justified trust is a bad thing, but trust makes systems
brittle, opaque, and costly to operate. Trust failures result in systemic
collapses, trust curation creates inequality and monopoly lock-in, and
naturally arising trust choke-points can be abused to deny access to
due process. Through the use of cryptographic proof and decentralized
networks Bitcoin minimizes and replaces these trust costs.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>With the available technology, there are fundamental trade-offs between
scale and decentralization. If the system is too costly people will be
forced to trust third parties rather than independently enforcing the
system’s rules. If the Bitcoin blockchain’s resource usage, relative
to the available technology, is too great, Bitcoin loses its competitive
advantages compared to legacy systems because validation will be too
costly (pricing out many users), forcing trust back into the system.
If capacity is too low and our methods of transacting too inefficient,
access to the chain for dispute resolution will be too costly, again
pushing trust back into the system.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Since Bitcoin is an electronic cash, it <em>isn’t</em> a generic database;
the demand for cheap highly-replicated perpetual storage is unbounded,
and Bitcoin cannot and will not satisfy that demand for non-ecash
(non-Bitcoin) usage, and there is no shame in that. Fortunately, Bitcoin
can interoperate with other systems that address other applications,
and–with luck and hard work–the Bitcoin system can and will satisfy
the world’s demand for electronic cash.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Fortunately, a lot of great technology is in the works that make
navigating the trade-offs easier.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>First up: after several years in the making Bitcoin Core has recently
merged libsecp256k1, which results in a huge increase in signature
validation performance. Combined with other recent work we’re now getting
ConnectTip performance 7x higher in 0.12 than in prior versions. This
has been a long time coming, and without its anticipation and earlier
work such as headers-first I probably would have been arguing for a
block size decrease last year. This improvement in the state of the
art for widely available production Bitcoin software sets a stage for
some capacity increases while still catching up on our decentralization
deficit. This shifts the bottlenecks off of CPU and more strongly onto
propagation latency and bandwidth.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Versionbits (BIP9) is approaching maturity and will allow the Bitcoin
network to have multiple in-flight soft-forks. Up until now we’ve had to
completely serialize soft-fork work, and also had no real way to handle
a soft-fork that was merged in core but rejected by the network. All
that is solved in BIP9, which should allow us to pick up the pace of
improvements in the network. It looks like versionbits will be ready
for use in the next soft-fork performed on the network.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>The next thing is that, at Scaling Bitcoin Hong Kong, Pieter Wuille
presented on bringing Segregated Witness to Bitcoin. What is proposed
is a <em>soft-fork</em> that increases Bitcoin’s scalability and capacity by
reorganizing data in blocks to handle the signatures separately, and in
doing so takes them outside the scope of the current blocksize limit.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>The particular proposal amounts to a 4MB blocksize increase at worst. The
separation allows new security models, such as skipping downloading data
you’re not going to check and improved performance for lite clients
(especially ones with high privacy). The proposal also includes fraud
proofs which make violations of the Bitcoin system provable with a compact
proof. This completes the vision of “alerts” described in the “Simplified
Payment Verification” section of the Bitcoin whitepaper, and would make it
possible for lite clients to enforce all the rules of the system (under
a new strong assumption that they’re not partitioned from someone who
would generate the proofs). The design has numerous other features like
making further enhancements safer and eliminating signature malleability
problems. If widely used this proposal gives a 2x capacity increase
(more if multisig is widely used), but most importantly it makes that
additional capacity–and future capacity beyond it–safer by increasing
efficiency and allowing more trade-offs (in particular, you can use much
less bandwidth in exchange for a strong non-partitioning assumption).</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>There is a working implementation (though it doesn’t yet have the fraud
proofs) at https://github.com/sipa/bitcoin/commits/segwit</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>(Pieter’s talk is at: transcript:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
slides:
https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/
Video: https://www.youtube.com/watch?v=fst1IK_mrng#t=36m )</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>I had good success deploying an earlier (hard-fork) version of segwit
in the Elements Alpha sidechain; the soft-fork segwit now proposed
is a second-generation design. And I think it’s quite reasonable to
get this deployed in a relatively short time frame. The segwit design
calls for a future bitcoinj compatible hardfork to further increase its
efficiency–but it’s not necessary to reap most of the benefits,and that
means it can happen on its own schedule and in a non-contentious manner.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Going beyond segwit, there has been some considerable activity brewing
around more efficient block relay. There is a collection of proposals,
some stemming from a p2pool-inspired informal sketch of mine and some
independently invented, called “weak blocks”, “thin blocks” or “soft
blocks”. These proposals build on top of efficient relay techniques
(like the relay network protocol or IBLT) and move virtually all the
transmission time of a block to before the block is found, eliminating
size from the orphan race calculation. We already desperately need this
at the current block sizes. These have not yet been implemented, but
fortunately the path appears clear. I’ve seen at least one more or less
complete specification, and I expect to see things running using this in a
few months. This tool will remove propagation latency from being a problem
in the absence of strategic behavior by miners. Better understanding
their behavior when miners behave strategically is an open question.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Concurrently, there is a lot of activity ongoing related to
“non-bandwidth” scaling mechanisms. Non-bandwidth scaling mechanisms
are tools like transaction cut-through and bidirectional payment channels
which increase Bitcoin’s capacity and speed using clever smart contracts
rather than increased bandwidth. Critically, these approaches strike right
at the heart of the capacity vs autotomy trade-off, and may allow us to
achieve very high capacity and very high decentralization. CLTV (BIP65),
deployed a month ago and now active on the network, is very useful for
these techniques (essential for making hold-up refunds work); CSV (BIP68
/ BIP112) is in the pipeline for merge in core and making good progress
(and will likely be ready ahead of segwit). Further Bitcoin protocol
improvements for non-bandwidth scaling are in the works: Many of these
proposals really want anti-malleability fixes (which would be provided
by segwit), and there are checksig flag improvements already tendered and
more being worked on, which would be much easier to deploy with segwit. I
expect that within six months we could have considerably more features
ready for deployment to enable these techniques. Even without them I
believe we’ll be in an acceptable position with respect to capacity
in the near term, but it’s important to enable them for the future.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>(http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning
is a relevant talk for some of the wanted network features for Lightning,
a bidirectional payment channel proposal which many parties are working
on right now; other non-bandwidth improvements discussed in the past
include transaction cut-through, which I consider a must-read for the
basic intuition about how transaction capacity can be greater than
blockchain capacity: https://bitcointalk.org/index.php?topic=281848.0 ,
though there are many others.)</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Further out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve
the alignment of incentives between miners and general node operators,
and prevent defection between the miners from undermining the fee
market behavior that will eventually fund security. I think that right
now capacity is high enough and the needed capacity is low enough that
we don’t immediately need these proposals, but they will be critically
important long term. I’m planning to help out and drive towards a more
concrete direction out of these proposals in the following months.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>(Relevant talks include
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/
)</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Finally–at some point the capacity increases from the above may not
be enough. Delivery on relay improvements, segwit fraud proofs, dynamic
block size controls, and other advances in technology will reduce the risk
and therefore controversy around moderate block size increase proposals
(such as 2/4/8 rescaled to respect segwit’s increase). Bitcoin will
be able to move forward with these increases when improvements and
understanding render their risks widely acceptable relative to the
risks of not deploying them. In Bitcoin Core we should keep patches
ready to implement them as the need and the will arises, to keep the
basic software engineering from being the limiting factor.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Our recent and current progress has well positioned the Bitcoin ecosystem
to handle its current capacity needs. I think the above sets out some
clear achievable milestones to continue to advance the art in Bitcoin
capacity while putting us in a good position for further improvement and
evolution.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>TL;DR: I propose we work immediately towards the segwit 4MB block
soft-fork which increases capacity and scalability, and recent speedups
and incoming relay improvements make segwit a reasonable risk. BIP9
and segwit will also make further improvements easier and faster to
deploy. We’ll continue to set the stage for non-bandwidth-increase-based
scaling, while building additional tools that would make bandwidth
increases safer long term. Further work will prepare Bitcoin for further
increases, which will become possible when justified, while also providing
the groundwork to make them justifiable.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Thanks for your time,</p>
</blockquote>
</blockquote>
<p>Wladimir J. van der Laan:</p>
<blockquote>
<blockquote>
<p>Sounds good to me.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>There are multiple ways to get involved in ongoing work, where the community</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>can help to make this happen sooner: …</p>
</blockquote>
</blockquote>
<p>Gavin Andresen:</p>
<blockquote>
<blockquote>
<p>Thanks for laying out a road-map, Greg.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>I’ll need to think about it some more, but just a couple of initial</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>reactions:</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>coinbase is messy and will just complicate consensus-critical code (as</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>opposed to making the right side of the merkle tree in block.version=5</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>blocks the segwitness data).</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>It will also make any segwitness fraud proofs significantly larger (merkle</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>path versus merkle path to coinbase transactions, plus ENTIRE coinbase</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>transaction, which might be quite large, plus merkle path up to root).</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>We also need to fix the O(n^2) sighash problem as an additional BIP for ANY</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>blocksize increase. That also argues for a hard fork– it is much easier to</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>fix it correctly and simplify the consensus code than to continue to apply</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>band-aid fixes on top of something fundamentally broken.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Segwitness will require a hard or soft-fork rollout, then a significant</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>fraction of the transaction-producing wallets to upgrade and start</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>supporting segwitness-style transactions. I think it will be much quicker</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>than the P2SH rollout, because the biggest transaction producers have a</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>strong motivation to lower their fees, and it won’t require a new type of</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>bitcoin address to fund wallets. But it still feels like it’ll be six</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>months to a year at the earliest before any relief from the current</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>problems we’re seeing from blocks filling up.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>Segwitness will make the current bottleneck (block propagation) a little</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>worse in the short term, because of the extra fraud-proof data. Benefits</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>well worth the costs.</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>——————</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>I think a barrier to quickly getting consensus might be a fundamental</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>difference of opinion on this:</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>“Even without them I believe we?ll be in an acceptable position with</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>respect to capacity in the near term”</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>The heaviest users of the Bitcoin network (businesses who generate tens of</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>thousands of transactions per day on behalf of their customers) would</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>strongly disgree; the current state of affairs is NOT acceptable to them.</p>
</blockquote>
</blockquote>
</div>
</article>
<div class="post-nav container">
<a class="prev button_outline" href="/Daniel-Blog/2016/02/06/bitcoin-bootstraping-business-in-bali-part-1/"><span>« Prev: Bitcoin & Bootstraping Business in Bali – Part 1</span>
</a>
<a class="next button_outline" href="/Daniel-Blog/why-peter-fee-market-wont-work"><span>» Next: Why Peter R’s Fee Market Wont Work</span>
</a>
</div>
<!-- Comments Start -->
<div class="comments">
<div id="disqus_thread" class="container"></div>
<script>
var disqus_config = function () {
this.page.url = 'http://Daunus.github.io/Daniel-Blog/maxwells-scaling-roadmap';
this.page.identifier = 'Greg Maxwells Roadmap for Bitcoin Scaling';
};
(function() {
var d = document, s = d.createElement('script');
s.src = '//'+'danielwilczynskiblog'+'.disqus.com/embed.js';
s.setAttribute('data-timestamp', +new Date());
(d.head || d.body).appendChild(s);
})();
</script>
<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
</div>
<!-- Comments End -->
<footer class="site-footer">
<div class="container flex-container">
<!-- Connect Social Icons Start -->
<ul class="social">
<li><a href="https://github.com/Daunus" target="_blank"><i class="icon fi-social-github"></i></a></li>
<li><a href="https://twitter.com/danWilcz" target="_blank"><i class="icon fi-social-twitter "></i></a></li>
</ul>
<!-- Connect Social Icons End -->
</div>
</footer>
<script src="/Daniel-Blog/assets/js/jquery-3.1.0.min.js"></script>
<script src="/Daniel-Blog/assets/js/typed.min.js"></script>
<script type="text/javascript">
var myQuotes = new Array();
myQuotes.push("<span>Inspiring quote1.</span>");
myQuotes.push("<span>Inspiring quote2. </span>");
$(".intro-post-title").typed({
strings: myQuotes,
typeSpeed: 10,
backDelay: 5000,
startDelay: 200,
loop: true,
loopCount: false,
cursorChar: "|"
});
$(".toggle-button").click(function(){
if($(this).text() === 'expand'){
$(this).text('collapse');
$(this).parent('div').find('.expandable').attr( "expanded", "true" );
}else{
$(this).text('expand');
$(this).parent('div').find('.expandable').attr( "expanded", "false" );
}
});
</script>
<script id="dsq-count-scr" src="//danielwilczynskiblog.disqus.com/count.js" async></script>
</body>
</html>