summaryrefslogtreecommitdiff
path: root/32/a18bd1e5101d934fe0895d225a5691a25fafe4
blob: 7ec5910135197a71767319a61d385591befb5180 (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
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
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AF14323
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 20:12:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03BF1256
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 20:12:45 +0000 (UTC)
Received: from mail-ig0-f175.google.com ([209.85.213.175]) by
	mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
	0Lc93r-1Z0OoD3ElZ-00jdSH for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 22:12:44 +0200
Received: by igbpg9 with SMTP id pg9so99595970igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 13:12:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.64.179 with SMTP id p19mr20776172igs.55.1439323964186;
	Tue, 11 Aug 2015 13:12:44 -0700 (PDT)
Received: by 10.50.104.198 with HTTP; Tue, 11 Aug 2015 13:12:43 -0700 (PDT)
In-Reply-To: <CALgxB7vGjgFgS4+hw7TomwuJ_UhZiyYybVekTM9A4sszZvj7dg@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<2547793.e4fEoOQyIR@coldstorage>
	<CAOG=w-thKPQUPx_ev3qzgkHjBfF3f_6EtFWq3QJdw1fETdnzhA@mail.gmail.com>
	<1623892.Xps1bl6nlD@coldstorage>
	<CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com>
	<20150811083806.4689995.85497.4220@thomaszander.se>
	<CADZB0_a93oDAEro-6h6UZprVyvRUTaB_tzggU8WUWKGJjbLeRw@mail.gmail.com>
	<CAOG=w-uNVaf68vVSwe0r+6WmUJUu76JQgMDrS4OryiiMhLr8vg@mail.gmail.com>
	<CALgxB7vGjgFgS4+hw7TomwuJ_UhZiyYybVekTM9A4sszZvj7dg@mail.gmail.com>
Date: Tue, 11 Aug 2015 21:12:43 +0100
Message-ID: <CALqxMTH7tgNBJULnLz+YtPDkLLr3zGpnb6RNCJeagoQ5AidDcg@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bd75cec9a2a11051d0eb94b
X-Provags-ID: V03:K0:l+gpqqAUwcWRrI4FiT/oe/tai0X2vJUzxnHEWAH/ge6tHDcwts6
	YqmLP0OTZ6MPBvkU/gtN7qODqfRE8SH5ephakImlA8YuwTz50XGwmi2sf1aJl/x8AgcM3mQ
	oJaqy9Bz37n6IUePNlFFk5O83TYyKoFRPWLxYtaVluNWGMYqMntJ9Ifn/bU3kemR1K0Uke3
	CrV0BiZQ8efUfpUAqhTaA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:VzmZ1Yk9Qzs=:XuWk3ymQh+q3vuL1zaWGcR
	WMHjhSAQS83C/KSOnDiDcJbjF0bEVV1WPfZxJeB+W2C4r0at/wRIYOl0uT62tik/OQRuN/BbT
	Gc8ysA0m4yr4EdWFh2W5YUFgtkZEQ+WL608NifmGAar6sz8ZClT0JxTvm4b0H8n0TOmwPgOZm
	eKJbWKwIGV7LJeV0FRgEVCyYMSETU5A0LMOscHASzfshf/5yGANQcJig6h8gTRIpdnpdIwP5y
	uEMWpFYIjY11WwYIZvWwm0hCH4gC04FH4YlkxC0z1cVq7o8sz1ASPd1v05lZ8Z8NTnWkvyEO/
	P0sT9ZH7eegZw1TWrz1DnI/Cac6b4YFreP5q1xqn9AkLh1JPHMboUeHjkwa5ROtw6Wk1icU3l
	7YtX0d2wOSOPT3IYr/tbAenRr+sOqWfGI3Ii//MJtruUAX/f2sO+ETKidYTm6cVBicf9RcTIW
	4tGdZUFkKfVmUYW4NvtZsx0MnFIGtOMrjkWsNaY0A7xApQ2f6sPNwOMGTwRE1KdaNNUzFL65/
	XyoGUzIWH/C/7r/Xum9UHI6oqacFW6kO537mN7ceYc6ofaF916BwhbE491qjLYAyuKirkSdcm
	SshO/4MRvkkEGp4l/GT3mUmwMX2UrqiuybvHaHxZP/HeOW9ufSa+bPPqx+HccX2UPMpXw29af
	5S7mXK+V/QQ6ZNl+p/QV5ocKBuqcMAFWpmRke1iMBJXHycwPteyrEarEbqO4+TXWY9K+1rBIf
	1MAEe5/b6UhV5bjE
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 20:12:48 -0000

--047d7bd75cec9a2a11051d0eb94b
Content-Type: text/plain; charset=UTF-8

I think everyone is expending huge effort on design, analysis and
implementation of the lowest cost technology for Bitcoin.

Changing parameters doesnt create progress on scalability fundamentals -
there really is an inherent cost and security / throughput tradeoff to
blockchains.  Security is quite central to this discussion.  It is
unrealistic in my opinion to suppose that everything can fit directly
on-chain in the fullest Bitcoin adoption across cash-payments, internet of
things, QoS, micropayments, share-trading, derivates etc.  Hence the
interest in protocols like lightning (encourage you and others to read the
paper, blog posts and implementation progress on the lightning-dev mailing
list).

Mid-term different tradeoffs can happen that are all connected to and
building on Bitcoin.  But whatever technologies win out for scale, they all
depend on Bitcoin security - anything built on Bitcoin requires a secure
base.  So I think it is logical that we strive to maintain and improve
Bitcoin security.  Long-term tradeoffs that significantly weaken security
for throughput or other considerations should be built on top of Bitcoin,
and avoiding creating a one-size fits all unfortunate compromise that
weakens Bitcoin to the lowest common denominator of centralisation,
insecurity and throughput tradeoffs.  This pattern (secure base, other
protocols built on top) is already the status quo - probably > 99% of
Bitcoin transactions are off-chain already (in exchanges, web wallets
etc).  And there are various things that can and are being done to improve
the security of those solutions, with provable reserves, periodic on-chain
settlement, netting, lightning like protocols and other things probably
still to be invented.

Some of the longer term things we probably dont know yet, but the future is
NOT bleak.  Lots of scope for technology improvement.

Adam


On 11 August 2015 at 20:26, Michael Naber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> All things considered, if people want to participate in a global consensus
> network, and the technology exist to do it at a lower cost, then is it
> sensible or even possible to somehow arbitrarily set the price of
> participating in a global consensus network to be expensive? Can someone
> please walk me through how that's expected to play out because I'm really
> having a hard time understanding how it could work.
>
>
>
> On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> More people using Bitcoin does not necessarily mean more transactions
>> being processed by the block chain. Satoshi was forward-thinking enough to
>> include a powerful script-signature system, something which has never
>> really existed before. Though suffering from some limitations to be sure,
>> this smart contract execution framework is expressive enough to enable a
>> wide variety of new features without changing bitcoin itself.
>>
>> One of these invented features is micropayment channels -- the ability
>> for two parties to rapidly exchange funds while only settling the final
>> balance to the block chain, and to do so in an entirely trustless way.
>> Right now people don't use scripts to do interesting things like this, but
>> there is absolutely no reason why they can't. Lightning network is a vision
>> of a future where everyone uses a higher-layer protocol for their
>> transactions which only periodically settle on the block chain. It is
>> entirely possible that you may be able to do all your day-to-day
>> transactions in bitcoin yet only settle accounts every other week, totaling
>> 13kB per year. A 1MB block could support that level of usage by 4 million
>> people, which is many orders of magnitude more than the number of people
>> presently using bitcoin on a day to day basis.
>>
>> And that, by the way, is without considering as-yet uninvented
>> applications of existing or future script which will provide even further
>> improvements to scale. This is very fertile ground being explored by very
>> few people. One thing I hope to come out of this block size debate is a lot
>> more people (like Joseph Poon) looking at how bitcoin script can be used to
>> enable new and innovative resource-efficient and privacy-enhancing payment
>> protocols.
>>
>> The network has room to grow. It just requires wallet developers and
>> other infrastructure folk to step up to the plate and do their part in
>> deploying this technology.
>>
>> On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon <gubatron@gmail.com> wrote:
>>
>>> - policy neutrality.
>>> - It can't be censored.
>>> - it can't be shut down
>>> - and the rules cannot change from underneath you.
>>>
>>> except it can be shutdown the minute it actually gets used by its
>>> inability to scale.
>>>
>>> what's the point of having all this if nobody can use it?
>>> what's the point of going through all that energy and CO2 for a mere
>>> 24,000 transactions an hour?
>>>
>>> It's clear that it's just a matter of time before it collapses.
>>>
>>> Here's a simple proposal (concept) that doesn't pretend to set a fixed
>>> block size limit as you can't ever know the demands the future will bring
>>> https://gist.github.com/gubatron/143e431ee01158f27db4
>>>
>>> We don't need to go as far as countries with hyper inflation trying to
>>> use the technology to make it collapse, anybody here who has distributed
>>> commercial/free end user software knows that any small company out there
>>> installs more copies in a couple weeks than all the bitcoin users we have
>>> at the moment, all we need is a single company/project with a decent amount
>>> of users who are now enabled to transact directly on the blockchain to
>>> screw it all up (perhaps OpenBazaar this winter could make this whole thing
>>> come down, hopefully they'll take this debate and the current limitations
>>> before their release, and boy are they coding nonstop on it now that they
>>> got funded), the last of your fears should be a malicious government trying
>>> to shut you down, for that to happen you must make an impact first, for now
>>> this is a silly game in the grand scheme of things.
>>>
>>> And you did sound pretty bad, all of his points were very valid and they
>>> share the concern of many people, many investors, entrepreneurs putting
>>> shitload of money, time and their lives on a much larger vision than that
>>> of a network that does a mere 3,500 tx/hour, but some people seem to be
>>> able to live in impossible or useless ideals.
>>>
>>> It's simply irresponsible to not want to give the network a chance to
>>> grow a bit more. Miners centralizing is inevitable given the POW based
>>> consensus, hobbists-mining is only there for countries with very cheap
>>> energy.
>>>
>>> If things remain this way, this whole thing will be a massive failure
>>> and it will probably take another decade before we can open our mouths
>>> about cryptocurrencies, decentralization and what not, and this stubornness
>>> will be the one policy that censored everyone, that shutdown everyone, that
>>> made the immutable rules not matter.
>>>
>>> Perhaps it will be Stellar what ends up delivering at this stubborn pace.
>>>
>>> http://twitter.com/gubatron
>>>
>>> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> >It follows then, that if we make a decision now which destroys that
>>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>>> pressure miners into changing rules contrary to user interests, then
>>>> Bitcoin is no longer interesting.
>>>>
>>>> You asked to be convinced of the need for bigger blocks. I gave that.
>>>> What makes you think bitcoin will break when more people use it?
>>>>
>>>> Sent on the go, excuse the brevity.
>>>> *From: *Mark Friedenbach
>>>> *Sent: *Tuesday, 11 August 2015 08:10
>>>> *To: *Thomas Zander
>>>> *Cc: *Bitcoin Dev
>>>> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>>>>
>>>> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>>>>> > This is where things diverge. It's fine to pick a new limit or growth
>>>>> > trajectory. But defend it with data and reasoned analysis.
>>>>>
>>>>> We currently serve about 0,007% of the world population sending maybe
>>>>> one
>>>>> transaction a month.
>>>>> This can only go up.
>>>>>
>>>>> There are about 20 currencies in the world that are unstable and
>>>>> showing early
>>>>> signs of hyperinflation. If even small percentage of these people
>>>>> cash-out and
>>>>> get Bitcoins for their savings you'd have the amount of people using
>>>>> Bitcoin
>>>>> as savings go from maybe half a million to 10 million in the space of
>>>>> a couple
>>>>> of months. Why so fast? Because all the world currencies are linked.
>>>>> Practically all currencies follow the USD, and while that one may stay
>>>>> robust
>>>>> and standing, the linkage has been shown in the past to cause
>>>>> chain-effects.
>>>>>
>>>>> It is impossible to predict how much uptake Bitcoin will take, but we
>>>>> have
>>>>> seen big rises in price as Cyprus had a bailin and then when Greece
>>>>> first
>>>>> showed bad signs again.
>>>>> Lets do our due diligence and agree that in the current world economy
>>>>> there
>>>>> are sure signs that people are considering Bitcoin on a big scale.
>>>>>
>>>>> Bigger amount of people holding Bitcoin savings won't make the
>>>>> transaction
>>>>> rate go up very much, but if you have feet on the ground you already
>>>>> see that
>>>>> people go back to barter in countries like Poland, Ireland, Greece etc.
>>>>> And Bitcoin will be an alternative to good to ignore.  Then
>>>>> transaction rates
>>>>> will go up. Dramatically.
>>>>>
>>>>> If you are asking for numbers, that is a bit tricky. Again; we are at
>>>>> 0,007%... Thats like a f-ing rounding error in the world economy. You
>>>>> can't
>>>>> reason from that. Its like using a float to do calculations that you
>>>>> should
>>>>> have done in a double and getting weird output.
>>>>>
>>>>> Bottom line is that a maximum size of 8Mb blocks is not that odd.
>>>>> Because a 20
>>>>> times increase is very common in a "company" that is about 6 years old.
>>>>> For instance Android was about that age when it started to get shipped
>>>>> by non-
>>>>> Google companies. There the increase was substantially bigger and the
>>>>> company
>>>>> backing it was definitely able to change direction faster than the
>>>>> Bitcoin
>>>>> oiltanker can change direction.
>>>>>
>>>>> ...
>>>>>
>>>>> Another metric to remember; if you follow hackernews (well, the
>>>>> incubator more
>>>>> than the linked articles) you'd be exposed to the thinking of these
>>>>> startups.
>>>>> Their only criteria is growth. and this is rather substantial growth.
>>>>> Like
>>>>> 150% per month.  Naturally, most of these build on top of html or other
>>>>> existing technologies.  But the point is that exponential growth is
>>>>> expected
>>>>> in any startup.  They typically have a much much more agressive
>>>>> timeline,
>>>>> though. Every month instead of every year.
>>>>> Having exponential growth in the blockchain is really not odd and even
>>>>> if we
>>>>> have LN or sidechains or the next changetip, this space will be used.
>>>>> And we
>>>>> will still have scarcity.
>>>>
>>>>
>>>> I'm sorry, I really don't want to sound like a jerk, but not a single
>>>> word of that mattered. Yes we all want Bitcoin to scale such that every
>>>> person in the world can use it without difficulty. However if that were all
>>>> that we cared about then I would be remiss if I did not point out that
>>>> there are plenty of better, faster, and cheaper solutions to finding global
>>>> consensus over a payment ledger than Bitcoin. Architectures which are
>>>> algorithmically superior in their scaling properties. Indeed they are
>>>> already implemented and you can use them today:
>>>>
>>>> https://www.stellar.org/
>>>> http://opentransactions.org/
>>>>
>>>> So why do I work on Bitcoin, and why do I care about the outcome of
>>>> this debate? Because Bitcoin offers one thing, and one thing only which
>>>> alternative architectures fundamentally lack: policy neutrality. It can't
>>>> be censored, it can't be shut down, and the rules cannot change from
>>>> underneath you. *That* is what Bitcoin offers that can't be replicated at
>>>> higher scale with a SQL database and an audit log.
>>>>
>>>> It follows then, that if we make a decision now which destroys that
>>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>>> pressure miners into changing rules contrary to user interests, then
>>>> Bitcoin is no longer interesting. We might as well get rid of mining at
>>>> that point and make Bitcoin look like Stellar or Open-Transactions because
>>>> at least then we'd scale even better and not be pumping millions of tons of
>>>> CO2 into the atmosphere from running all those ASICs.
>>>>
>>>> On the other side, 3Tb harddrives are sold, which take 8Mb blocks
>>>>> without
>>>>> problems.
>>>>>
>>>>
>>>> Straw man, storage is not an issue.
>>>>
>>>>
>>>>> You can buy broadband in every relevant country that easily supports
>>>>> the
>>>>> bandwidth we need. (remember we won't jump to 8Mb in a day, it will
>>>>> likely
>>>>> take at least 6 months).
>>>>>
>>>>
>>>> Neither one of those assertions is clear. Keep in mind the goal is to
>>>> have Bitcoin survive active censorship. Presumably that means being able to
>>>> run a node even in the face of a hostile ISP or government. Furthermore, it
>>>> means being location independent and being able to move around. In many
>>>> places the higher the bandwidth requirements the fewer the number of ISPs
>>>> that are available to service you, and the more visible you are.
>>>>
>>>> It may also be necessary to be able to run over Tor. And not just
>>>> today's Tor which is developed, serviced, and supported by the US
>>>> government, but a Tor or I2P that future governments have turned hostile
>>>> towards and actively censor or repress. Or existing authoritative
>>>> governments, for that matter. How much bandwidth would be available through
>>>> those connections?
>>>>
>>>> It may hopefully never be necessary to operate under such constraints,
>>>> except by freedom seeking individuals within existing totalitarian regimes.
>>>> However the credible threat of doing so may be what keeps Bitcoin from
>>>> being repressed in the first place. Lose the capability to go underground,
>>>> and it will be pressured into regulation, eventually.
>>>>
>>>> To the second point, it has been previously pointed out that large
>>>> miners stand to gain from larger blocks, for the same basic underlying
>>>> reasons as selfish mining. The incentive is to increase blocks, and miners
>>>> are able to do so at will and without cost. I would not be so certain that
>>>> we wouldn't see large blocks sooner than that.
>>>>
>>>>
>>>>> We should get the inverted bloom filters stuff (or competing products)
>>>>> working
>>>>> at least on a one-to-one basis so we can solve the propagation time
>>>>> problem.
>>>>> There frankly is a huge amount of optimization that can be done in
>>>>> that area,
>>>>> we don't even use locality (pingtime) to optimize distribution.
>>>>> From my experience you can expect a 2-magnitude speedup in that same 6
>>>>> month
>>>>> period by focusing some research there.
>>>>>
>>>>
>>>> This is basically already deployed thanks to Matt's relay network.
>>>> Further improvements are not going to have dramatic effects.
>>>>
>>>>
>>>>> Remember 8Gb/block still doesn't support VISA/Mastercard.
>>>>>
>>>>
>>>> No, it doesn't. And 8GB/block is ludicrously large -- it would
>>>> absolutely, without any doubt destroy the very nature of Bitcoin, turning
>>>> it into a fundamentally uninteresting reincarnation of the existing
>>>> financial system. And still be unable to compete with VISA/Mastercard.
>>>>
>>>> So why then the pressure to go down a route that WILL lead to failure
>>>> by your own metrics?
>>>>
>>>> I humbly suggest that maybe we should play the strengths of Bitcoin
>>>> instead -- it's trustlessness via policy neutrality.
>>>>
>>>> Either that, or go work on Stellar. Because that's where it's headed
>>>> otherwise.
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--047d7bd75cec9a2a11051d0eb94b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think everyone is expending huge effort on design, analy=
sis and implementation of the lowest cost technology for Bitcoin.<div><br><=
/div><div>Changing parameters doesnt create progress on scalability fundame=
ntals - there really is an inherent cost and security / throughput tradeoff=
 to blockchains.=C2=A0 Security is quite central to this discussion.=C2=A0 =
It is unrealistic in my opinion to suppose that everything can fit directly=
 on-chain in the fullest Bitcoin adoption across cash-payments, internet of=
 things, QoS, micropayments, share-trading, derivates etc.=C2=A0 Hence the =
interest in protocols like lightning (encourage you and others to read the =
paper, blog posts and implementation progress on the lightning-dev mailing =
list). =C2=A0</div><div><br></div><div>Mid-term different tradeoffs can hap=
pen that are all connected to and building on Bitcoin.=C2=A0 But whatever t=
echnologies win out for scale, they all depend on Bitcoin security - anythi=
ng built on Bitcoin requires a secure base.=C2=A0 So I think it is logical =
that we strive to maintain and improve Bitcoin security.=C2=A0 Long-term tr=
adeoffs that significantly weaken security for throughput or other consider=
ations should be built on top of Bitcoin, and avoiding creating a one-size =
fits all unfortunate compromise that weakens Bitcoin to the lowest common d=
enominator of centralisation, insecurity and throughput tradeoffs.=C2=A0 Th=
is pattern (secure base, other protocols built on top) is already the statu=
s quo - probably &gt; 99% of Bitcoin transactions are off-chain already (in=
 exchanges, web wallets etc).=C2=A0 And there are various things that can a=
nd are being done to improve the security of those solutions, with provable=
 reserves, periodic on-chain settlement, netting, lightning like protocols =
and other things probably still to be invented.</div><div><br></div><div>So=
me of the longer term things we probably dont know yet, but the future is N=
OT bleak.=C2=A0 Lots of scope for technology improvement.</div><div><br></d=
iv><div>Adam</div><div><br></div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On 11 August 2015 at 20:26, Michael Naber via bitcoin=
-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">All things c=
onsidered, if people want to participate in a global consensus network, and=
 the technology exist to do it at a lower cost, then is it sensible or even=
 possible to somehow arbitrarily set the price of participating in a global=
 consensus network to be expensive? Can someone please walk me through how =
that&#39;s expected to play out because I&#39;m really having a hard time u=
nderstanding how it could work.<div><br></div><div><br></div></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitc=
oin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
><div>More people using Bitcoin does not necessarily mean more transactions=
 being processed by the block chain. Satoshi was forward-thinking enough to=
 include a powerful script-signature system, something which has never real=
ly existed before. Though suffering from some limitations to be sure, this =
smart contract execution framework is expressive enough to enable a wide va=
riety of new features without changing bitcoin itself.<br><br></div>One of =
these invented features is micropayment channels -- the ability for two par=
ties to rapidly exchange funds while only settling the final balance to the=
 block chain, and to do so in an entirely trustless way. Right now people d=
on&#39;t use scripts to do interesting things like this, but there is absol=
utely no reason why they can&#39;t. Lightning network is a vision of a futu=
re where everyone uses a higher-layer protocol for their transactions which=
 only periodically settle on the block chain. It is entirely possible that =
you may be able to do all your day-to-day transactions in bitcoin yet only =
settle accounts every other week, totaling 13kB per year. A 1MB block could=
 support that level of usage by 4 million people, which is many orders of m=
agnitude more than the number of people presently using bitcoin on a day to=
 day basis.<br><br></div>And that, by the way, is without considering as-ye=
t uninvented applications of existing or future script which will provide e=
ven further improvements to scale. This is very fertile ground being explor=
ed by very few people. One thing I hope to come out of this block size deba=
te is a lot more people (like Joseph Poon) looking at how bitcoin script ca=
n be used to enable new and innovative resource-efficient and privacy-enhan=
cing payment protocols.<br><br></div>The network has room to grow. It just =
requires wallet developers and other infrastructure folk to step up to the =
plate and do their part in deploying this technology.<br></div><div><div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 11, 201=
5 at 2:14 AM, Angel Leon <span dir=3D"ltr">&lt;<a href=3D"mailto:gubatron@g=
mail.com" target=3D"_blank">gubatron@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">-<span style=3D"font-size:13px=
"> policy neutrality.=C2=A0</span><div><span style=3D"font-size:13px">- It =
can&#39;t be censored.</span></div><div><span style=3D"font-size:13px">- it=
 can&#39;t be shut down</span></div><div><span style=3D"font-size:13px">- a=
nd the rules cannot change from underneath you.<br><br></span><div>except i=
t can be shutdown the minute it actually gets used by its inability to scal=
e.<br><br>what&#39;s the point of having all this if nobody can use it?<br>=
what&#39;s the point of going through all that energy and CO2 for a mere 24=
,000 transactions an hour?<br><br>It&#39;s clear that it&#39;s just a matte=
r of time before it collapses.<br><br>Here&#39;s a simple proposal (concept=
) that doesn&#39;t pretend to set a fixed block size limit as you can&#39;t=
 ever know the demands the future will bring <a href=3D"https://gist.github=
.com/gubatron/143e431ee01158f27db4" target=3D"_blank">https://gist.github.c=
om/gubatron/143e431ee01158f27db4</a> <br><br>We don&#39;t need to go as far=
 as countries with hyper inflation trying to use the technology to make it =
collapse, anybody here who has distributed commercial/free end user softwar=
e knows that any small company out there installs more copies in a couple w=
eeks than all the bitcoin users we have at the moment, all we need is a sin=
gle company/project with a decent amount of users who are now enabled to tr=
ansact directly on the blockchain to screw it all up (perhaps OpenBazaar th=
is winter could make this whole thing come down, hopefully they&#39;ll take=
 this debate and the current limitations before their release, and boy are =
they coding nonstop on it now that they got funded), the last of your fears=
 should be a malicious government trying to shut you down, for that to happ=
en you must make an impact first, for now this is a silly game in the grand=
 scheme of things.</div><div><br>And you did sound pretty bad, all of his p=
oints were very valid and they share the concern of many people, many inves=
tors, entrepreneurs putting shitload of money, time and their lives on a mu=
ch larger vision than that of a network that does a mere 3,500 tx/hour, but=
 some people seem to be able to live in impossible or useless ideals.=C2=A0=
</div><div><br></div><div>It&#39;s simply irresponsible to not want to give=
 the network a chance to grow a bit more. Miners centralizing is inevitable=
 given the POW based consensus, hobbists-mining is only there for countries=
 with very cheap energy.<br><br>If things remain this way, this whole thing=
 will be a massive failure and it will probably take another decade before =
we can open our mouths about cryptocurrencies, decentralization and what no=
t, and this stubornness will be the one policy that censored everyone, that=
 shutdown everyone, that made the immutable rules not matter.<br><br>Perhap=
s it will be Stellar what ends up delivering at this stubborn pace.</div></=
div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div><a href=3D=
"http://twitter.com/gubatron" target=3D"_blank">http://twitter.com/gubatron=
</a><br></div></div>
<br><div class=3D"gmail_quote"><div><div>On Tue, Aug 11, 2015 at 4:38 AM, T=
homas Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div><div><div style=3D"background-color:rgb(255,255,255);line-heigh=
t:initial">                                                                =
                      <div style=3D"width:100%;font-size:initial;font-famil=
y:Calibri,&#39;Slate Pro&#39;,sans-serif;color:rgb(31,73,125);text-align:in=
itial;background-color:rgb(255,255,255)"><span style=3D"color:rgb(0,0,0);fo=
nt-family:sans-serif">&gt;It follows then, that if we make a decision now w=
hich destroys that property, which makes it possible to censor bitcoin, to =
deny service, or to pressure miners into changing rules contrary to user in=
terests, then Bitcoin is no longer interesting. </span></div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-s=
erif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,2=
55)"><span style=3D"color:rgb(0,0,0);font-family:sans-serif"><br></span></d=
iv><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slat=
e Pro&#39;,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)"><span style=3D"color:rgb(0,0,0);font-family:sans-seri=
f">You asked to be convinced of the need for bigger blocks. I gave that.</s=
pan></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#=
39;Slate Pro&#39;,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)"><span style=3D"color:rgb(0,0,0);font-family:sa=
ns-serif">What makes you think bitcoin will break when more people use it?<=
/span></div>                                                               =
                                                                      <div =
style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#3=
9;,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(=
255,255,255)"><br style=3D"display:initial"></div>                         =
                                                                           =
                                                                           =
                    <div style=3D"font-size:initial;font-family:Calibri,&#3=
9;Slate Pro&#39;,sans-serif;color:rgb(31,73,125);text-align:initial;backgro=
und-color:rgb(255,255,255)">Sent=C2=A0on=C2=A0the=C2=A0go,=C2=A0excuse=C2=
=A0the=C2=A0brevity.=C2=A0</div>                                           =
                                                                           =
                                                            <table style=3D=
"background-color:white;border-spacing:0px" width=3D"100%"> <tbody><tr><td =
colspan=3D"2" style=3D"font-size:initial;text-align:initial;background-colo=
r:rgb(255,255,255)">                           <div style=3D"border-style:s=
olid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;paddi=
ng:3pt 0in 0in;font-family:Tahoma,&#39;BB Alpha Sans&#39;,&#39;Slate Pro&#3=
9;;font-size:10pt">  <div><b>From: </b>Mark Friedenbach</div><div><b>Sent: =
</b>Tuesday, 11 August 2015 08:10</div><div><b>To: </b>Thomas Zander</div><=
div><b>Cc: </b>Bitcoin Dev</div><div><b>Subject: </b>Re: [bitcoin-dev] Fees=
 and the block-finding process</div></div></td></tr></tbody></table><div st=
yle=3D"border-style:solid none none;border-top-color:rgb(186,188,209);borde=
r-top-width:1pt;font-size:initial;text-align:initial;background-color:rgb(2=
55,255,255)"></div><br><div><div dir=3D"ltr">On Mon, Aug 10, 2015 at 11:31 =
PM, Thomas Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Monday 10. A=
ugust <a href=3D"tel:2015%2023.03.39" value=3D"+12015230339" target=3D"_bla=
nk">2015 23.03.39</a> Mark Friedenbach wrote:<br>
&gt; This is where things diverge. It&#39;s fine to pick a new limit or gro=
wth<br>
&gt; trajectory. But defend it with data and reasoned analysis.<br>
<br>
</span>We currently serve about 0,007% of the world population sending mayb=
e one<br>
transaction a month.<br>
This can only go up.<br>
<br>
There are about 20 currencies in the world that are unstable and showing ea=
rly<br>
signs of hyperinflation. If even small percentage of these people cash-out =
and<br>
get Bitcoins for their savings you&#39;d have the amount of people using Bi=
tcoin<br>
as savings go from maybe half a million to 10 million in the space of a cou=
ple<br>
of months. Why so fast? Because all the world currencies are linked.<br>
Practically all currencies follow the USD, and while that one may stay robu=
st<br>
and standing, the linkage has been shown in the past to cause chain-effects=
.<br>
<br>
It is impossible to predict how much uptake Bitcoin will take, but we have<=
br>
seen big rises in price as Cyprus had a bailin and then when Greece first<b=
r>
showed bad signs again.<br>
Lets do our due diligence and agree that in the current world economy there=
<br>
are sure signs that people are considering Bitcoin on a big scale.<br>
<br>
Bigger amount of people holding Bitcoin savings won&#39;t make the transact=
ion<br>
rate go up very much, but if you have feet on the ground you already see th=
at<br>
people go back to barter in countries like Poland, Ireland, Greece etc.<br>
And Bitcoin will be an alternative to good to ignore.=C2=A0 Then transactio=
n rates<br>
will go up. Dramatically.<br>
<br>
If you are asking for numbers, that is a bit tricky. Again; we are at<br>
0,007%... Thats like a f-ing rounding error in the world economy. You can&#=
39;t<br>
reason from that. Its like using a float to do calculations that you should=
<br>
have done in a double and getting weird output.<br>
<br>
Bottom line is that a maximum size of 8Mb blocks is not that odd. Because a=
 20<br>
times increase is very common in a &quot;company&quot; that is about 6 year=
s old.<br>
For instance Android was about that age when it started to get shipped by n=
on-<br>
Google companies. There the increase was substantially bigger and the compa=
ny<br>
backing it was definitely able to change direction faster than the Bitcoin<=
br>
oiltanker can change direction.<br>
<br>
...<br>
<br>
Another metric to remember; if you follow hackernews (well, the incubator m=
ore<br>
than the linked articles) you&#39;d be exposed to the thinking of these sta=
rtups.<br>
Their only criteria is growth. and this is rather substantial growth. Like<=
br>
150% per month.=C2=A0 Naturally, most of these build on top of html or othe=
r<br>
existing technologies.=C2=A0 But the point is that exponential growth is ex=
pected<br>
in any startup.=C2=A0 They typically have a much much more agressive timeli=
ne,<br>
though. Every month instead of every year.<br>
Having exponential growth in the blockchain is really not odd and even if w=
e<br>
have LN or sidechains or the next changetip, this space will be used. And w=
e<br>
will still have scarcity.</blockquote><div>=C2=A0<br></div><div>I&#39;m sor=
ry, I really don&#39;t want to sound like a jerk, but not a single word of =
that mattered. Yes we all want Bitcoin to scale such that every person in t=
he world can use it without difficulty. However if that were all that we ca=
red about then I would be remiss if I did not point out that there are plen=
ty of better, faster, and cheaper solutions to finding global consensus ove=
r a payment ledger than Bitcoin. Architectures which are algorithmically su=
perior in their scaling properties. Indeed they are already implemented and=
 you can use them today:<br><br><a href=3D"https://www.stellar.org/" target=
=3D"_blank">https://www.stellar.org/</a><br><a href=3D"http://opentransacti=
ons.org/" target=3D"_blank">http://opentransactions.org/</a><br><br></div><=
div>So why do I work on Bitcoin, and why do I care about the outcome of thi=
s debate? Because Bitcoin offers one thing, and one thing only which altern=
ative architectures fundamentally lack: policy neutrality. It can&#39;t be =
censored, it can&#39;t be shut down, and the rules cannot change from under=
neath you. *That* is what Bitcoin offers that can&#39;t be replicated at hi=
gher scale with a SQL database and an audit log.<br><br></div><div>It follo=
ws then, that if we make a decision now which destroys that property, which=
 makes it possible to censor bitcoin, to deny service, or to pressure miner=
s into changing rules contrary to user interests, then Bitcoin is no longer=
 interesting. We might as well get rid of mining at that point and make Bit=
coin look like Stellar or Open-Transactions because at least then we&#39;d =
scale even better and not be pumping millions of tons of CO2 into the atmos=
phere from running all those ASICs.<br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

On the other side, 3Tb harddrives are sold, which take 8Mb blocks without<b=
r>
problems.<br>
</blockquote><div><br></div><div>Straw man, storage is not an issue.<br></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">You can buy broadband in=
 every relevant country that easily supports the<br>
bandwidth we need. (remember we won&#39;t jump to 8Mb in a day, it will lik=
ely<br>
take at least 6 months).<br></blockquote><div><br></div><div>Neither one of=
 those assertions is clear. Keep in mind the goal is to have Bitcoin surviv=
e active censorship. Presumably that means being able to run a node even in=
 the face of a hostile ISP or government. Furthermore, it means being locat=
ion independent and being able to move around. In many places the higher th=
e bandwidth requirements the fewer the number of ISPs that are available to=
 service you, and the more visible you are.<br><br></div><div>It may also b=
e necessary to be able to run over Tor. And not just today&#39;s Tor which =
is developed, serviced, and supported by the US government, but a Tor or I2=
P that future governments have turned hostile towards and actively censor o=
r repress. Or existing authoritative governments, for that matter. How much=
 bandwidth would be available through those connections?<br><br></div><div>=
It may hopefully never be necessary to operate under such constraints, exce=
pt by freedom seeking individuals within existing totalitarian regimes. How=
ever the credible threat of doing so may be what keeps Bitcoin from being r=
epressed in the first place. Lose the capability to go underground, and it =
will be pressured into regulation, eventually.<br><br></div><div>To the sec=
ond point, it has been previously pointed out that large miners stand to ga=
in from larger blocks, for the same basic underlying reasons as selfish min=
ing. The incentive is to increase blocks, and miners are able to do so at w=
ill and without cost. I would not be so certain that we wouldn&#39;t see la=
rge blocks sooner than that.<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
We should get the inverted bloom filters stuff (or competing products) work=
ing<br>
at least on a one-to-one basis so we can solve the propagation time problem=
.<br>There frankly is a huge amount of optimization that can be done in tha=
t area,<br>
we don&#39;t even use locality (pingtime) to optimize distribution.<br>
From my experience you can expect a 2-magnitude speedup in that same 6 mont=
h<br>
period by focusing some research there.<br>


</blockquote><div><br></div><div>This is basically already deployed thanks =
to Matt&#39;s relay network. Further improvements are not going to have dra=
matic effects.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Remember=
 8Gb/block still doesn&#39;t support VISA/Mastercard.<br></blockquote><div>=
<br></div><div>No, it doesn&#39;t. And 8GB/block is ludicrously large -- it=
 would absolutely, without any doubt destroy the very nature of Bitcoin, tu=
rning it into a fundamentally uninteresting reincarnation of the existing f=
inancial system. And still be unable to compete with VISA/Mastercard.<br><b=
r></div><div>So why then the pressure to go down a route that WILL lead to =
failure by your own metrics?<br><br></div><div>I humbly suggest that maybe =
we should play the strengths of Bitcoin instead -- it&#39;s trustlessness v=
ia policy neutrality.<br><br></div><div>Either that, or go work on Stellar.=
 Because that&#39;s where it&#39;s headed otherwise.<br></div></div></div><=
/div>
<br></div></div>
<br></div></div><span>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--047d7bd75cec9a2a11051d0eb94b--