summaryrefslogtreecommitdiff
path: root/f8/bfc575fba549e0936c3730c3cc2e8f5a127718
blob: 0bbe033af8bb5c6bd6edf792ba81cb0c66645d91 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <marcel@jamin.net>) id 1Z4k4B-0006d1-Vq
	for bitcoin-development@lists.sourceforge.net;
	Tue, 16 Jun 2015 06:09:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of jamin.net
	designates 209.85.213.52 as permitted sender)
	client-ip=209.85.213.52; envelope-from=marcel@jamin.net;
	helo=mail-yh0-f52.google.com; 
Received: from mail-yh0-f52.google.com ([209.85.213.52])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z4k49-0000cg-IW
	for bitcoin-development@lists.sourceforge.net;
	Tue, 16 Jun 2015 06:09:47 +0000
Received: by yhpn97 with SMTP id n97so4857380yhp.0
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 15 Jun 2015 23:09:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=LOtOW78S86ayIwvaXtAOTtkA6KEG1fyP+QkUOCau2QE=;
	b=X1XaRQ+ZTC7zR9h9o3xoPDO8e7Z6x8wBSW/InKHiAVdut4jc0Y9Wcx/FYsbTCSpoDP
	oHknaP0hu+s/6VCJsoRVmV2wtAkTWOaBNilEyfPKejA847zErffV24JBGQU8dVDh/pRS
	OetEt+K5oFtH/utDi5FPIKiuAl022vLDC78aTLhi/5SCRBLwcQVoNvAsKiMErT8SK/ME
	RG/pyv5qscF95J9xVgls3iIdWRfHXp657MBM+1oFV8WaHfOZWMeBsk3OAU7272RfpsbN
	WUWOkgawJTyI4jyFUhe/BsZoVwBKaNXZffMA/lKkoPnlol+9Xzi0mRTNnXR4AbTBHoG2
	26Vw==
X-Gm-Message-State: ALoCoQlcE9y3W5BPGz56rthfI7PBpTbl+f72vLL5sskA7Q/b/ZCrTtLBZSnE88VDhgsRoJmkU7lu
MIME-Version: 1.0
X-Received: by 10.170.69.131 with SMTP id l125mr38407887ykl.39.1434434979860; 
	Mon, 15 Jun 2015 23:09:39 -0700 (PDT)
Received: by 10.13.224.69 with HTTP; Mon, 15 Jun 2015 23:09:39 -0700 (PDT)
In-Reply-To: <557FB198.7080905@mail.bihthai.net>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
	<CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
	<557FB198.7080905@mail.bihthai.net>
Date: Tue, 16 Jun 2015 08:09:39 +0200
Message-ID: <CAAUq486pFWJaOK0NOSmV41ofu=a7_kzM-c0SCgtnvXfHwx6F5w@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: venzen@mail.bihthai.net
Content-Type: multipart/alternative; boundary=001a1139d8ec6da9b005189c6b51
X-Spam-Score: -0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
	[URIs: xtnodes.com]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Z4k49-0000cg-IW
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
 non-consensus hard-fork
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 06:09:48 -0000

--001a1139d8ec6da9b005189c6b51
Content-Type: text/plain; charset=UTF-8

> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.

Neither do you or anyone else.

> There is protocol for how change is effected in a FOSS project.

And it allows the minority to hold the majority hostage.

> If you take the risks with Mike&GavCoin, that would be fine, but you are
about to take them with community-owned Bitcoin and Other People's Money!

The same can be said about the other camp.

BitcoinXT is not going to fork the chain on a specific date no matter what.
People will be able to vote via block versions and once a sufficient
majority supports the extensions, everyone else will have a grace period to
upgrade. Only after that is a very small minority at risk of losing money.

That being said, I'd rather see a solution that everyone agrees on. My
personal opinion/hope is that Mike and Gavin are just applying pressure
where it's needed. But in the end, they can do whatever they want if they
have the necessary support. Permissionless innovation is one of bitcoins
virtues. In the end, only adoption will decide what bitcoin is and isn't.

2015-06-16 7:18 GMT+02:00 Venzen <venzen@mail.bihthai.net>:

> Mike Hearn,
>
> In the light of your responses to Adam Back's questions, below, I feel
> it is time to speak up because what I now understand, and is implied,
> is that Mike Hearn and Gavin Andresen have planned and deployed the
> infrastructure for a Bitcoin hard-fork and intend to action it despite
> majority opposition.  http://xtnodes.com/
>
> I'll try to keep it brief:
>
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus. Your actions are bad for the
> Bitcoin project and its ideals, disrespectful of your peers and years
> of their passionate hard work, and dangerous for Bitcoin in the
> marketplace and bitcoin in peoples' wallets.
>
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it. Your hard-fork is tantamount to theft and you and
> your collaborators will effectively ex-communicate yourselves from
> this project and community. It appears that you are consciously trying
> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
> You clearly do not comprehend the array of risks - especially the
> unanticipated ones. As the market saying goes: "If you think
> speculation is easy, it is because you are ignorant about the risks".
> If you take the risks with Mike&GavCoin, that would be fine, but you
> are about to take them with community-owned Bitcoin and Other People's
> Money!
>
> You are causing a lot of stress, unnecessarily, and grave concern
> surrounds your proposed renegade action. You can dissolve the threat:
> those players to whom you have made promises can be appeased and
> eventually get most of what they need from this FOSS project. The
> developers whom you are railroading to get your way, and the way in
> which you are doing it, is about to cause a schism that will expand
> outward from this community.
>
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
> If an individual in an objectively agreed-to FOSS-modelled
> collaborative project has the audacity to threaten his peers and the
> world with a unilateral hard-fork despite majority objection and a
> probability distribution that includes terminal risks and unintended
> consequences, then what would an impartial outsider think? Some of
> their thoughts would include that the antagonist could be acting in
> self-interest, or may be a paid actor, or worse, a saboteur. What
> would they advise? Stop that individual, at once!
>
> Bitcoin is a Free and Open Source Software project that serves as
> flagship for the blockchain. It has a payment network but the key
> benefits are censorship resistance and trustless decentralization.
> There is protocol for how change is effected in a FOSS project. For
> the sake of everything that is good and useful in Bitcoin, reconsider
> your dangerous plan and its intended and unintended consequences. Put
> your feet back on the ground, return to the fold and let the
> collaborative FOSS model, and the skills available here, gradually
> scale Bitcoin to your (and all our) grand vision.
>
> Venzen Khaosan
>
>
> On 06/15/2015 04:56 PM, Mike Hearn wrote:
> > Hi Adam,
> >
> > Provisional answers below!
> >
> > - Are you releasing a BIP for that proposal for review?
> >
> >
> > The work splits like this:
> >
> > * Gavin is writing the code and I think a BIP as well
> >
> > * I will review both and mostly delegate to Gavin's good taste
> > around the details, unless there is some very strong disagreement.
> > But that seems unlikely.
> >
> > * I have been handling gitian and the patch rebases, the code
> > signing and so on, so far. I've also been doing some work to setup
> > the basic infrastructure of the project (website etc).
> >
> >
> > - If the reviewers all say NACK will you take on board their
> > suggestions?
> >
> >
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> > requests aren't scored in any way. The final decision rests with
> > the maintainer as in ~all open source projects.
> >
> >
> >
> > - On the idea of a non-consensus hard-fork at all, I think we can
> > assume you will get a row of NACKs.  Can you explain your
> > rationale for going ahead anyway?  The risks are well understood
> > and enormous.
> >
> >
> > Yes, I have been working on an article that explains how we got to
> > this point from my perspective. It is quite long, but only because
> > I want it to be readable for people who weren't following the
> > debate.
> >
> > Anyway, I think I've laid out the gist of it over and over again,
> > but to summarise:
> >
> > If Bitcoin runs out of capacity *it will break and many of our
> > users will leave*. That is not an acceptable outcome for myself or
> > the many other wallet, service and merchant developers who have
> > worked for years to build an ecosystem around this protocol.
> >
> >
> >
> > - How do you propose to deal with the extra risks that come from
> > non-consensus hard-forks?  Hard-forks themselves are quite risky,
> > but non-consensus ones are extremely dangerous for consensus.
> >
> >
> > The approach is the same for other forks. Voting via block versions
> > and then when there's been >X% for Y time units the 1mb limit is
> > lifted/replaced.
> >
> >
> >
> >
> > - If you're going it alone as it were, are you proposing that you
> > will personally maintain bitcoin-XT?  Or do you have a plan to
> > later hand over maintenance to the bitcoin developers?
> >
> >
> > Good question!  I have various thoughts on this, but let's wait and
> > see what happens first. Perhaps the new chain won't get the
> > majority on it.
> >
> > In the event that the >1mb chain does eventually win, I would
> > expect Core to apply the patch and rejoin the consensus rather than
> > lose all its users. That would take XT back to being a fairly small
> > patchset to improve the network protocol.
> >
> >
> >
> > - Do you have contingency plans for what to do if the
> > non-consensus hard-fork goes wrong and $3B is lost as a result?
> >
> >
> > Where did you get the $3B figure from? The fork either doesn't
> > happen, or it happens after quite a long period of people knowing
> > it's going to happen - for example because their full node is
> > printing "You need to upgrade" messages due to seeing the larger
> > block version, or because they read the news, or because they heard
> > about it via some other mechanisms.
> >
> > Let me flip the question around. Do you have a contingency plan if
> > Bitcoin runs out of capacity and significant user disruption occurs
> > that results in exodus, followed by fall in BTC price? The only one
> > I've seen is "we can perform an emergency hard fork in a few
> > weeks"!
> >
> >
> >
> > As you can probably tell I think a unilateral fork without
> > wide-scale consensus from the technical and business communities is
> > a deeply inadvisable.
> >
> >
> > Gavin and I have been polling many key players in the ecosystem.
> > The consensus you seek does exist. All wallet developers (except
> > Lawrence), all the major exchanges, all the major payment
> > processors and many of the major mining pools want to see the limit
> > lifted (I haven't been talking to pools, Gavin has).
> >
> > This notion that the change has no consensus is based on you
> > polling the people directly around you and people who like to spend
> > all day on this mailing list. It's not an accurate reflection of
> > the wider Bitcoin community and that is one of the leading reasons
> > there is going to be a fork. A small number of people have been
> > flatly ignoring LOTS of highly technical and passionate developers
> > who have written vast amounts of code, built up the Bitcoin user
> > base, designed hardware and software, and yes built companies.
> >
> > How do you think that makes Bitcoin Core look to the rest of the
> > Bitcoin world? How much confidence does that give people?
> >
> >
> >
> > Of the overall process, I think you can agree we should not be
> > making technical decisions with this level of complexity and
> > consensus risk with financial implications of this magnitude under
> > duress of haste?
> >
> >
> > This debate will never end until a fork makes it irrelevant. There
> > is no process for ending it, despite me begging Wladimir to make
> > one.
> >
> > And there is no haste. We have been debating the block size limit
> > for _years_. We have known it must be lifted for _years_. I kicked
> > off this current round of debates after realising that Wladimir's
> > release timeline wouldn't allow a block size limit to be released
> > before the end of the year. The reason we're talking about it now
> > and not next year is exactly to ensure there is plenty of time.
> >
> >
> >
> >
> > I can sincerely assure you everyone does want to scale bitcoin and
> > shares your long term objective on that
> >
> >
> > I really wish you were right, and I definitely feel you are one of
> > the more reasonable ones Adam. But the overwhelming impression I
> > get from a few others here is that no, they don't want to scale
> > Bitcoin. They already decided it's a technological dead end. They
> > want to kick end users out in order to "incentivise" (force) the
> > creation of some other alternative, claiming that it's still
> > Bitcoin whilst ignoring basic details ... like the fact that no
> > existing wallets or services would work.
> >
> > Scaling Bitcoin can only be achieved by letting it grow, and
> > letting people tackle each bottleneck as it arises at the right
> > times. Not by convincing ourselves that success is failure.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________ Bitcoin-development
> > mailing list Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr"><div>&gt;=C2=A0<span style=3D"font-size:12.8000001907349px=
">Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,</span=
></div><span style=3D"font-size:12.8000001907349px">you cannot have it.</sp=
an><div><br></div><div>Neither do you or anyone else.</div><div><br></div><=
div>&gt;=C2=A0<span style=3D"font-size:12.8000001907349px">There is protoco=
l for how change is effected in a FOSS project.</span><br></div><div><div><=
span style=3D"font-size:12.8000001907349px"><br></span></div><div><span sty=
le=3D"font-size:12.8000001907349px">And it allows the minority to</span><sp=
an style=3D"font-size:12.8000001907349px">=C2=A0hold the majority hostage.<=
/span></div><div><span style=3D"font-size:12.8000001907349px"><br></span></=
div><div><span style=3D"font-size:12.8000001907349px">&gt;=C2=A0</span><spa=
n style=3D"font-size:12.8000001907349px">If you take the risks with Mike&am=
p;GavCoin, that would be fine, but you=C2=A0</span><span style=3D"font-size=
:12.8000001907349px">are about to take them with community-owned Bitcoin an=
d Other People&#39;s=C2=A0</span><span style=3D"font-size:12.8000001907349p=
x">Money!</span><br></div></div><div><span style=3D"font-size:12.8000001907=
349px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">T=
he same can be said about the other camp.</span></div><div><span style=3D"f=
ont-size:12.8000001907349px"><br></span></div><div><span style=3D"font-size=
:12.8000001907349px">BitcoinXT is not going to fork the chain on a specific=
 date no matter what. People will be able to vote via block versions and on=
ce a sufficient majority supports the extensions, everyone else will have a=
 grace period to upgrade. Only after that is a very small minority at risk =
of losing money.</span></div><div><span style=3D"font-size:12.8000001907349=
px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">That=
 being said, I&#39;d rather see a solution that everyone agrees on. My pers=
onal opinion/hope is that Mike and Gavin are just applying pressure where i=
t&#39;s needed. But in the end, they can do whatever they want if they have=
 the necessary support.=C2=A0</span><span style=3D"font-size:12.80000019073=
49px">Permissionless innovation is one of bitcoins virtues. In the end, onl=
y adoption will decide what bitcoin is and isn&#39;t.</span></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-06-16 7:18 GMT+=
02:00 Venzen <span dir=3D"ltr">&lt;<a href=3D"mailto:venzen@mail.bihthai.ne=
t" target=3D"_blank">venzen@mail.bihthai.net</a>&gt;</span>:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">Mike Hearn,<br>
<br>
In the light of your responses to Adam Back&#39;s questions, below, I feel<=
br>
it is time to speak up because what I now understand, and is implied,<br>
is that Mike Hearn and Gavin Andresen have planned and deployed the<br>
infrastructure for a Bitcoin hard-fork and intend to action it despite<br>
majority opposition.=C2=A0 <a href=3D"http://xtnodes.com/" rel=3D"noreferre=
r" target=3D"_blank">http://xtnodes.com/</a><br>
<br>
I&#39;ll try to keep it brief:<br>
<br>
Mike Hearn, you should cease your activity of a unilateral hard-fork<br>
immediately. You are doing untold damage by breaking FOSS governance<br>
protocol requiring methodical collaborative work and due process of<br>
change implementation by consensus. Your actions are bad for the<br>
Bitcoin project and its ideals, disrespectful of your peers and years<br>
of their passionate hard work, and dangerous for Bitcoin in the<br>
marketplace and bitcoin in peoples&#39; wallets.<br>
<br>
Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,<br>
you cannot have it. Your hard-fork is tantamount to theft and you and<br>
your collaborators will effectively ex-communicate yourselves from<br>
this project and community. It appears that you are consciously trying<br>
to usurp ownership and maintenance of Bitcoin. As if it is that easy!<br>
You clearly do not comprehend the array of risks - especially the<br>
unanticipated ones. As the market saying goes: &quot;If you think<br>
speculation is easy, it is because you are ignorant about the risks&quot;.<=
br>
If you take the risks with Mike&amp;GavCoin, that would be fine, but you<br=
>
are about to take them with community-owned Bitcoin and Other People&#39;s<=
br>
Money!<br>
<br>
You are causing a lot of stress, unnecessarily, and grave concern<br>
surrounds your proposed renegade action. You can dissolve the threat:<br>
those players to whom you have made promises can be appeased and<br>
eventually get most of what they need from this FOSS project. The<br>
developers whom you are railroading to get your way, and the way in<br>
which you are doing it, is about to cause a schism that will expand<br>
outward from this community.<br>
<br>
You may accuse the community for being antagonistic to you, and<br>
therefore uncooperative, but it is plain to see that your bullheaded<br>
manner eventually generates antagonism wherever you go. Taking Bitcoin<br>
away from this community, in anger, won&#39;t solve the problem and will<br=
>
be like killing the goose that lays the golden eggs.<br>
<br>
If an individual in an objectively agreed-to FOSS-modelled<br>
collaborative project has the audacity to threaten his peers and the<br>
world with a unilateral hard-fork despite majority objection and a<br>
probability distribution that includes terminal risks and unintended<br>
consequences, then what would an impartial outsider think? Some of<br>
their thoughts would include that the antagonist could be acting in<br>
self-interest, or may be a paid actor, or worse, a saboteur. What<br>
would they advise? Stop that individual, at once!<br>
<br>
Bitcoin is a Free and Open Source Software project that serves as<br>
flagship for the blockchain. It has a payment network but the key<br>
benefits are censorship resistance and trustless decentralization.<br>
There is protocol for how change is effected in a FOSS project. For<br>
the sake of everything that is good and useful in Bitcoin, reconsider<br>
your dangerous plan and its intended and unintended consequences. Put<br>
your feet back on the ground, return to the fold and let the<br>
collaborative FOSS model, and the skills available here, gradually<br>
scale Bitcoin to your (and all our) grand vision.<br>
<br>
Venzen Khaosan<br>
<span class=3D""><br>
<br>
On 06/15/2015 04:56 PM, Mike Hearn wrote:<br>
&gt; Hi Adam,<br>
&gt;<br>
&gt; Provisional answers below!<br>
&gt;<br>
&gt; - Are you releasing a BIP for that proposal for review?<br>
&gt;<br>
&gt;<br>
&gt; The work splits like this:<br>
&gt;<br>
</span>&gt; * Gavin is writing the code and I think a BIP as well<br>
&gt;<br>
&gt; * I will review both and mostly delegate to Gavin&#39;s good taste<br>
<span class=3D"">&gt; around the details, unless there is some very strong =
disagreement.<br>
&gt; But that seems unlikely.<br>
&gt;<br>
</span>&gt; * I have been handling gitian and the patch rebases, the code<b=
r>
<span class=3D"">&gt; signing and so on, so far. I&#39;ve also been doing s=
ome work to setup<br>
&gt; the basic infrastructure of the project (website etc).<br>
&gt;<br>
&gt;<br>
&gt; - If the reviewers all say NACK will you take on board their<br>
&gt; suggestions?<br>
&gt;<br>
&gt;<br>
&gt; Feedback will be read. There are no NACKS in Bitcoin XT. Patch<br>
&gt; requests aren&#39;t scored in any way. The final decision rests with<b=
r>
&gt; the maintainer as in ~all open source projects.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - On the idea of a non-consensus hard-fork at all, I think we can<br>
&gt; assume you will get a row of NACKs.=C2=A0 Can you explain your<br>
&gt; rationale for going ahead anyway?=C2=A0 The risks are well understood<=
br>
&gt; and enormous.<br>
&gt;<br>
&gt;<br>
&gt; Yes, I have been working on an article that explains how we got to<br>
&gt; this point from my perspective. It is quite long, but only because<br>
&gt; I want it to be readable for people who weren&#39;t following the<br>
&gt; debate.<br>
&gt;<br>
&gt; Anyway, I think I&#39;ve laid out the gist of it over and over again,<=
br>
&gt; but to summarise:<br>
&gt;<br>
</span>&gt; If Bitcoin runs out of capacity *it will break and many of our<=
br>
&gt; users will leave*. That is not an acceptable outcome for myself or<br>
<div><div class=3D"h5">&gt; the many other wallet, service and merchant dev=
elopers who have<br>
&gt; worked for years to build an ecosystem around this protocol.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - How do you propose to deal with the extra risks that come from<br>
&gt; non-consensus hard-forks?=C2=A0 Hard-forks themselves are quite risky,=
<br>
&gt; but non-consensus ones are extremely dangerous for consensus.<br>
&gt;<br>
&gt;<br>
&gt; The approach is the same for other forks. Voting via block versions<br=
>
&gt; and then when there&#39;s been &gt;X% for Y time units the 1mb limit i=
s<br>
&gt; lifted/replaced.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - If you&#39;re going it alone as it were, are you proposing that you<=
br>
&gt; will personally maintain bitcoin-XT?=C2=A0 Or do you have a plan to<br=
>
&gt; later hand over maintenance to the bitcoin developers?<br>
&gt;<br>
&gt;<br>
&gt; Good question!=C2=A0 I have various thoughts on this, but let&#39;s wa=
it and<br>
&gt; see what happens first. Perhaps the new chain won&#39;t get the<br>
&gt; majority on it.<br>
&gt;<br>
&gt; In the event that the &gt;1mb chain does eventually win, I would<br>
&gt; expect Core to apply the patch and rejoin the consensus rather than<br=
>
&gt; lose all its users. That would take XT back to being a fairly small<br=
>
&gt; patchset to improve the network protocol.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - Do you have contingency plans for what to do if the<br>
&gt; non-consensus hard-fork goes wrong and $3B is lost as a result?<br>
&gt;<br>
&gt;<br>
&gt; Where did you get the $3B figure from? The fork either doesn&#39;t<br>
&gt; happen, or it happens after quite a long period of people knowing<br>
&gt; it&#39;s going to happen - for example because their full node is<br>
&gt; printing &quot;You need to upgrade&quot; messages due to seeing the la=
rger<br>
&gt; block version, or because they read the news, or because they heard<br=
>
&gt; about it via some other mechanisms.<br>
&gt;<br>
&gt; Let me flip the question around. Do you have a contingency plan if<br>
&gt; Bitcoin runs out of capacity and significant user disruption occurs<br=
>
&gt; that results in exodus, followed by fall in BTC price? The only one<br=
>
&gt; I&#39;ve seen is &quot;we can perform an emergency hard fork in a few<=
br>
&gt; weeks&quot;!<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; As you can probably tell I think a unilateral fork without<br>
&gt; wide-scale consensus from the technical and business communities is<br=
>
&gt; a deeply inadvisable.<br>
&gt;<br>
&gt;<br>
&gt; Gavin and I have been polling many key players in the ecosystem.<br>
&gt; The consensus you seek does exist. All wallet developers (except<br>
&gt; Lawrence), all the major exchanges, all the major payment<br>
&gt; processors and many of the major mining pools want to see the limit<br=
>
&gt; lifted (I haven&#39;t been talking to pools, Gavin has).<br>
&gt;<br>
&gt; This notion that the change has no consensus is based on you<br>
&gt; polling the people directly around you and people who like to spend<br=
>
&gt; all day on this mailing list. It&#39;s not an accurate reflection of<b=
r>
&gt; the wider Bitcoin community and that is one of the leading reasons<br>
&gt; there is going to be a fork. A small number of people have been<br>
&gt; flatly ignoring LOTS of highly technical and passionate developers<br>
&gt; who have written vast amounts of code, built up the Bitcoin user<br>
&gt; base, designed hardware and software, and yes built companies.<br>
&gt;<br>
&gt; How do you think that makes Bitcoin Core look to the rest of the<br>
&gt; Bitcoin world? How much confidence does that give people?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Of the overall process, I think you can agree we should not be<br>
&gt; making technical decisions with this level of complexity and<br>
&gt; consensus risk with financial implications of this magnitude under<br>
&gt; duress of haste?<br>
&gt;<br>
&gt;<br>
&gt; This debate will never end until a fork makes it irrelevant. There<br>
&gt; is no process for ending it, despite me begging Wladimir to make<br>
&gt; one.<br>
&gt;<br>
&gt; And there is no haste. We have been debating the block size limit<br>
</div></div>&gt; for _years_. We have known it must be lifted for _years_. =
I kicked<br>
<span class=3D"im HOEnZb">&gt; off this current round of debates after real=
ising that Wladimir&#39;s<br>
&gt; release timeline wouldn&#39;t allow a block size limit to be released<=
br>
&gt; before the end of the year. The reason we&#39;re talking about it now<=
br>
&gt; and not next year is exactly to ensure there is plenty of time.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I can sincerely assure you everyone does want to scale bitcoin and<br>
&gt; shares your long term objective on that<br>
&gt;<br>
&gt;<br>
&gt; I really wish you were right, and I definitely feel you are one of<br>
&gt; the more reasonable ones Adam. But the overwhelming impression I<br>
&gt; get from a few others here is that no, they don&#39;t want to scale<br=
>
&gt; Bitcoin. They already decided it&#39;s a technological dead end. They<=
br>
&gt; want to kick end users out in order to &quot;incentivise&quot; (force)=
 the<br>
&gt; creation of some other alternative, claiming that it&#39;s still<br>
&gt; Bitcoin whilst ignoring basic details ... like the fact that no<br>
&gt; existing wallets or services would work.<br>
&gt;<br>
&gt; Scaling Bitcoin can only be achieved by letting it grow, and<br>
&gt; letting people tackle each bottleneck as it arises at the right<br>
&gt; times. Not by convincing ourselves that success is failure.<br>
&gt;<br>
&gt;<br>
&gt;<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">&gt; -----------------------=
-------------------------------------------------------<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________ Bitcoin-development<br=
>
&gt; mailing list <a href=3D"mailto:Bitcoin-development@lists.sourceforge.n=
et">Bitcoin-development@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/l=
ists/listinfo/bitcoin-development</a><br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br></div>

--001a1139d8ec6da9b005189c6b51--