-
Notifications
You must be signed in to change notification settings - Fork 0
/
feed.xml
763 lines (594 loc) · 41 KB
/
feed.xml
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
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Daniel Wilczynski</title>
<description>Biographical Page & Bitcoin Blog</description>
<link>http://Daunus.github.io/Daniel-Blog/</link>
<atom:link href="http://Daunus.github.io/Daniel-Blog/feed.xml" rel="self" type="application/rss+xml"/>
<pubDate>Tue, 08 Nov 2016 17:04:42 +0700</pubDate>
<lastBuildDate>Tue, 08 Nov 2016 17:04:42 +0700</lastBuildDate>
<generator>Jekyll v3.0.5</generator>
<item>
<title>Bitcoin & Bootstraping Business in Bali – Part 2</title>
<description><p>This is the second part of my post about bootstrapping and living in Bali. The first talks about the Bitcoin scene in Bali.</p>
<p>Bali, Indonesia is fast becoming a popular hub for location independent freelancers, entrepreneurs and a great place to knuckle down and work in a pleasant and fun environment.</p>
<p>From October till December 2015 I was working on my new Bitcoin related business there.</p>
<h2>Why Bootstrap In Bali</h2>
<p>Bali is a beautiful and interesting place where you will enjoy staying. The costs are really low and you can optimise your time to get a lot of work done and then relax <img src="/Daniel-Blog/assets/images/bali-2-a.png" alt="Bali rice terraces" style="float:left;padding:10px;" width="300" height="225" />when you need to. Its affordable to eat out everyday, pay for all your washing, cleaning and any other time sucking tasks that need to be done back home. Everything is very close and little to no time has to be spent on commuting.</p>
<p>There are many co-working spaces and its easy to meet other entrepreneurs/freelancers etc.</p>
<p>The co-working space that I attended most was Hubud. There were a lot of bloggers there, people trying to figure out ways to make money and freelancers/remote workers.</p>
<p>There were not many people there building and running their own businesses. I was told by one business owner that these people prefer to work from home.</p>
<p><img src="/Daniel-Blog/assets/images/bali-2-b.png" alt="Seminyak Bali" style="float:right;padding:10px;" width="300" height="225" /></p>
<p>There are also a few technology and business related meet-ups. The IT meetup I attended had about 30 people show up mostly expats and some locals.</p>
<p>The one major downside is that getting a fast internet connection is a hard task. Internet in cafes and hotels when it existed was only good enough for browsing and maybe watching a low quality streaming video.</p>
<p>The co-working spaces have good enough internet but even then do not expect mind blowing speeds. It took around 24 hours to download an 8GB update to my laptop.</p>
<h2>Where To Stay</h2>
<h3>Ubud:</h3>
<p><img src="/Daniel-Blog/assets/images/bali-2-c.png" alt="Ubud, Bali" style="float:left;padding:10px;" width="300" height="225" /></p>
<p>A very serene town of around 20 000 among the rice terraces in the volcanic foothills of Bali. Its the most popular location for freelancers, location-independent entrepreneurs and Yoga lovers. Its also a great place to experience traditional Balinese culture.</p>
<p>Ubud has a few co-working spaces, the biggest being Hubud where membership can be paid for by Bitcoin and which has a Bitcoin ATM. Hubud is where you can find Gary and connect with the Bitcoin community. Hubud has a great atmosphere and very open community. You can get a lot of work done but also meet some interesting people. Its the co-working space where I spent the most time.</p>
<p><img src="/Daniel-Blog/assets/images/bali-2-d.png" alt="Near Ubud" style="float:right;padding:10px;" width="300" height="225" /></p>
<p>Onion Collective is another co-working area/hostel where its possible to buy food with Bitcoin. There are maybe two more smaller co-working spaces that I did not visit.</p>
<p>Ubud is a great place to take a family and has many outdoor activities and great places to eat. It can get a bit quiet and is not the best place if you are looking for a party.</p>
<h3>Kuta-Seminyak Area:</h3>
<p><img src="/Daniel-Blog/assets/images/bali-2-e.png" alt="Kuta, Bali" style="float:left;padding:10px;" width="300" height="225" /></p>
<p>These are very crowded areas full of tourists and party-goers. Seminyak is slightly more upscale and calmer. It can be fun but might not be the best place if you are looking to get work done. There are many distractions and its hard to find other ‘digital nomads’. Its a great place for learning to surf, Muay Thai, partying and getting drunk (and there is nothing wrong with any of that 🙂 ).</p>
<p>LineUpHub is one co-working space located there. Its a smallish space where people are busy working and there is little socialising. Its frequented by people who are staying in Bali for a shorter period.</p>
<h3>Canggu:</h3>
<p>I would describe it as a cross between Seminyak and Ubud by the beach. Its a popular surfing destination in a semi-rural setting (in ten years I suspect it will be more like Seminyak). It has a few busy night spots. There is a nice co-working space there, Dojo Bali. I only spend half a day in Canggu so do not know more.</p>
<p><img src="/Daniel-Blog/assets/images/bali-2-f.png" alt="LineUpHub" style="float:right;padding:10px;" width="300" height="225" /></p>
<h3>Sanur:</h3>
<p>Sanur is a built up but quiet area by the beach, popular with older tourists and families. The co-working space there is Kumpul.</p>
<h2>When To Go</h2>
<p>December to March is wet season when the southern built up areas including beaches become dirty. The rest of the year is hot and humid with little rain.</p>
<h2>Cost</h2>
<p><img src="/Daniel-Blog/assets/images/bali-2-g.png" alt="My Apartment" style="float:left;padding:10px;" width="300" height="225" /></p>
<p>My apartment was $AUD 400 / month including air-conditioner, Internet (slow but usable), weekly room service, small fridge and all bills. This was for a 50 day rental. Short term accommodation is more expensive. Its is possible to find similar accommodation at a compound for about $200 per month. The compounds are an enclosed collection of separate houses where locals live and rent out houses. They can be very nice.</p>
<p><img src="/Daniel-Blog/assets/images/bali-2-h.png" alt="My Apartment" style="float:right;padding:10px;" width="300" height="225" /></p>
<p>I ate local food which I enjoyed and was much cheaper, about $4 would give me two dishes to fill me up. All my expenses excluding accommodation were about $AUD 80 per week.</p>
<p>Give Bali a try and feel free to ask me any questions here.</p>
</description>
<pubDate>Tue, 16 Feb 2016 05:08:35 +0700</pubDate>
<link>http://Daunus.github.io/Daniel-Blog/2016/02/15/bitcoin-bootstraping-business-in-bali-part-2-2/</link>
<guid isPermaLink="true">http://Daunus.github.io/Daniel-Blog/2016/02/15/bitcoin-bootstraping-business-in-bali-part-2-2/</guid>
<category>bitcoin</category>
<category>Bali</category>
<category>personal</category>
</item>
<item>
<title>Bitcoin & Bootstraping Business in Bali – Part 1</title>
<description><p>Bali, Indonesia is fast becoming a popular hub for location independent freelancers, entrepreneurs and a great place to knuckle down and work in a pleasant and fun environment.
<img src="/Daniel-Blog/assets/images/bali-1-a.png" alt="Bali rice terraces" style="float:right;padding:10px;" width="347" height="260" /></p>
<p>From October till December 2015 I was working on my new Bitcoin related business (btcstores.co) there. I thought to write this post about the Bitcoin scene in Bali, as well as the general startup/freelancer scene.</p>
<p>Note that while I have done a lot of touristy travelling before, I have not been to popular startup hubs like San Francisco or London, or location independent hubs like Saigon or Chiang Mai. Hence comparisons might be lacking.</p>
<h2>Bitcoin In Bali AKA BitIsland</h2>
<p>Bali has probably around 40 Bitcoin accepting businesses. Thats a lot compared to my hometown Adelaide, Australia where I am yet to find a Bitcoin accepting merchant. Adelaide and Bali have similar populations. Local Bitcoiners are trying to turn Bali into BitIsland and they are doing a fine job.</p>
<p>Its possible to pay for food, accommodation, co-working, scooter rental, phone credit and much more with Bitcoin. I even got some business cards designed and printed by a bitcoin-accepting studio that by coincidence was on the same street as my accommodation!</p>
<p><a href="http://bitislands.com/">bitislands.com</a>
<a href="http://directory.bitcoin.co.id/">directory.bitcoin.co.id</a></p>
<p>Indonesian Bitcoin Directories</p>
<p>The one issue is that many of these Bitcoin accepting merchants tend to be more in the mid to upper price range, and I was trying to live on a budget.</p>
<p><img src="/Daniel-Blog/assets/images/bali-1-b.png" alt="Gary Dykstra" style="float:left; padding:10px;" width="199" height="265" /></p>
<p>A lot of this is the result of the work of Gary Dykstra, Christine Chiang and a small group of dedicated and passionate people (my apologies to people who I omitted through forgetfulness). They have been hitting the pavement convincing local businesses in Ubud to accept Bitcoin. They also organise events like Bitcoin Film Festival and Bitcoin 101 learning sessions. The highlight is “The Filter” a weekly recorded Bitcoin meet-up in the Hubud co-working space.</p>
<p><img src="/Daniel-Blog/assets/images/bali-1-c.png" alt="Christine Chiang" style="float:right;padding:10px;" width="199" height="265" /></p>
<p>The meet-up is well attended by roughly ten people on average, there are always some regulars and new faces as people come and go to Bali.</p>
<p>I also had the pleasure to meet one Bitcoiner who runs a broker/exchange in Europe from Bali. It is very similar to my old exchange in Australia that unfortunately had to be closed down due to bank issues (on that note if anybody wants to cooperate on a new Bitcoin related business contact me).</p>
<p><img src="/Daniel-Blog/assets/images/bali-1-d.png" alt="The Filter" style="float:left;padding:10px;" width="293" height="219" /></p>
<p>The largest Indonesian Bitcoin exchange and 10th largest in the world is based in Bali. To sell Bitcoins for IDR I would simply go to their office and the whole encounter only took a few minutes. I did have to provide my ID on the first visit however.</p>
<p><img src="/Daniel-Blog/assets/images/bali-1-e.png" alt="Bitcoin Exchange" style="float:right;padding:10px;" width="304" height="228" /></p>
<p>The exchange price is often lower then the ‘world’ price so there are arbitrage opportunities. This is due to a large amount of expats cashing out their Bitcoin, to presumably live the good life in Bali. Nevertheless, I was buying Bitcoins through Localbitcoins in Australia and selling them in Bali. That worked out cheaper for me then converting through my bank. I do have a good reputation on Localbitcoins and can get a good price, though.</p>
<p>The exchange has also played a big part in promoting local merchants to accept Bitcoins through their POS system. Its CEO has put great effort to turning Bali into BitIsland and for that reason relocated there.</p>
<p><img src="/Daniel-Blog/assets/images/bali-1-f.png" alt="Bitcoin Exchange After Work Hours" style="float:left;padding:10px;" width="328" height="246" /></p>
<p>I find it interesting, and so might readers, to know the involvement of Indonesians in Bitcoin.</p>
<p>Gary and Christine are US citizens staying in Bali for an extended period. Most of the participants of the meet-ups were expats from all over the world, with a few Indonesians occasionally. The small studio that produced my business cards was run and owned by Indonesians. I presume many of the more expensive hotels and restaurants that accept Bitcoin are owned by expats.</p>
<p>The Indonesian exchange is owned and run by Indonesians.</p>
<p>Next Week, Part 2 – Bootstraping a business in Bali, Why/Where/What</p>
</description>
<pubDate>Mon, 14 Dec 2015 05:08:35 +0700</pubDate>
<link>http://Daunus.github.io/Daniel-Blog/2016/02/06/bitcoin-bootstraping-business-in-bali-part-1/</link>
<guid isPermaLink="true">http://Daunus.github.io/Daniel-Blog/2016/02/06/bitcoin-bootstraping-business-in-bali-part-1/</guid>
<category>bitcoin</category>
<category>Bali</category>
<category>personal</category>
</item>
<item>
<title>Greg Maxwells Roadmap for Bitcoin Scaling</title>
<description><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>
</description>
<pubDate>Mon, 14 Dec 2015 05:08:35 +0700</pubDate>
<link>http://Daunus.github.io/Daniel-Blog/maxwells-scaling-roadmap</link>
<guid isPermaLink="true">http://Daunus.github.io/Daniel-Blog/maxwells-scaling-roadmap</guid>
<category>bitcoin</category>
</item>
<item>
<title>Why Peter R’s Fee Market Wont Work</title>
<description><p>At the first Scaling Bitcoin conference Peter R presented his ideas on why a fee market would exist without a block size limit. You can see his presentation here: https://www.youtube.com/watch?v=ad0Pjj_ms2k.</p>
<p>He is wrong and I will explain why.</p>
<p>Peter says that a non-zero supply curve exists because increasing block size increases cost to miners due to higher orphan rate. I have also heard a variation of this argument with increasing block size being constrained by hardware resources, internet bandwidth etc.</p>
<p>Theoretically these arguments are correct, practically they are not.</p>
<p>The effect of block size on these costs is almost negligible.</p>
<p>The supply curve is not exactly flat but very close to it. It is practically (if not theoretically) flat and at zero. In reality a fee market will not form.</p>
<p>As an example, we have a supply and demand curve for oxygen but there is no real market for it because its impractical for something so cheap with such a flat and low curve. Yes, Oxygen does have a supply curve because humans are capable of increasing its supply at an increasing cost.</p>
<p>When curves meet at extremes the market breaks down.</p>
<p>No block size limit would simply result in huge blocks and a much more centralised node network, that can be easier influenced by governments.</p>
<p>But lets ignore all of the above for a second.</p>
<p>Peter also says we need at least 2 mining pools, for a market to form based on the orphan rate cost. Of course you hardly have much of a market with 2 pools, or 5-10 pools. That is what we have now. You can not have a real efficient market for orphan rates with only a few participants at one end.</p>
<p>Furthermore, orphan rate is a result of block propagation and can be decreased by moving pools closer together geographically. That is obviously very negative if we are trying to prevent mining centralisation.</p>
<p>To quote Gregory Maxwell:</p>
<blockquote>
<blockquote>
<p>How could you have written at such length and complexity but ignoring the simple expident miners have of simply centeralizing their operation around larger pools to lower their costs– an activity they previously performed, in practice, not just theory (which was walked back by handing them more efficient relay mechenisms) and which is simple, easy, and which reduces those marginal costs to 0 at the limit (e.g. all miners served off a particular host) — after I specifically called you out on this previously? Doubly so when your analysis gives provides a framework for analyizing the profitibility of moving from one point on that income tradeoff graph to another (e.g. the lost income from failing to centeralize)….</p>
</blockquote>
</blockquote>
<p>You might ask, why can a fee market form with fixed block-size supply then? After-all we still have only a small number of pools? The reason is, that in Peter’s model the cost variable is due to the differing orphan rate between pools. That is not true for fixed block size. There is no variable for the supply curve. Thats why the supply curve is a straight vertical line.</p>
<p>Finally Peter refers to the block size limit as some ‘artificial centrally controlled limit’.</p>
<p>He does raise a good and important point here. In the situation of a fee-market based on limited block size, what would be the mechanism for changing the block-size limit and who would have control? The solutions from Peter R or others did not satisfy me personally. It is a valid question though. Are we to have a hard-fork each time we decide the fees are getting too high or low? Do we implement code to allow a semi-centralised authority to decide? These do not seem like good solutions.</p>
<p>To say it is a centrally controlled limit is wrong however. To change the limit needs the consensus of the network i.e. nodes. Core developers have some limited ability to influence people, but ultimately they can not force through any change by themselves, they need the networks tacit agreement. Nobody and everybody controls the limit. Its control is decentralised (and therefore hard to change).</p>
<p>Finally there is nothing exceptionally artificial about the limit. Bitcoin itself is artificial, the 21 million limit is also an arbitrary artificial limit. Humans set the parameters of Bitcoin, its supply and its block size limit. The problem and difference is the 21 million limit does not have to change. Block size limit might have to, how will that be decided?</p>
</description>
<pubDate>Tue, 01 Dec 2015 05:08:35 +0700</pubDate>
<link>http://Daunus.github.io/Daniel-Blog/why-peter-fee-market-wont-work</link>
<guid isPermaLink="true">http://Daunus.github.io/Daniel-Blog/why-peter-fee-market-wont-work</guid>
<category>economics</category>
<category>bitcoin</category>
</item>
<item>
<title>Why This Blog?</title>
<description><p>At this point BIP 101 was released around 4 months ago and the second ‘Scaling Bitcoin Conference’ is 2 weeks away.</p>
<p>There is an active debate about the direction of Bitcoin and I have many new thoughts about the economic and political issues, that I want to contribute to the debate. I want maximum exposure for these view, hence my starting this blog.</p>
<p>I will also be writing technical posts related to digital currencies. I will not be adding anything new here as there are many people with vastly greater knowledge.</p>
<p>My aim with technical posts is to improve my understanding, and the guides might prove useful to other people with similar educational aspirations.</p>
</description>
<pubDate>Tue, 24 Nov 2015 05:08:35 +0700</pubDate>
<link>http://Daunus.github.io/Daniel-Blog/why-i-started-this-blog</link>
<guid isPermaLink="true">http://Daunus.github.io/Daniel-Blog/why-i-started-this-blog</guid>
<category>personal</category>
<category>bitcoin</category>
</item>
</channel>
</rss>