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
|
Return-Path: <post@levinkeller.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C9403EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 15:03:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com
[209.85.217.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BE601F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 15:03:37 +0000 (UTC)
Received: by lbbsx3 with SMTP id sx3so84010226lbb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 08:03:35 -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:references:in-reply-to:from:date
:message-id:subject:to:cc:content-type;
bh=CXO088c1hCB7ggfYVyqB1a6DLcqE0ALtG6Vra5WJa6A=;
b=BWn/UNqgk0ryVsmMmd7JuQfDvnTLgPuYcEHEegHvMYk6mtnBBvtKH8y5djvsu9wMbP
DRycmut4/06vydEyKUysvTaXFxsjXRepu6hB+gLr9JrSpBOhkIxre3+ynLcSnfaWEP8U
Sudz0ZFeBfBT5umZIhZJXAmaNKQuIcgFPzhzzP4jtuIZIu3ydh93Uw2UoJdfJ9OJF2lE
DP1wt12Ji5/6gMho7NVgsoe+cxPZC3Xfogb8E1R1n7VKL+Njl3HStfFcMn1FRs6GoJf7
qzh58MaE+KM7H+B0FbGhsKzZikaLHPITGBtJXujeLPRUgYdsaTdV5LkVVrq5rZkN23x1
9eyQ==
X-Gm-Message-State: ALoCoQkhICgfAsV70WO6pkp3U9thb9dzUGkutBO3htksfqOa5vbAMEFbntZs9KhjZ9+dKZWfMA5q
X-Received: by 10.112.170.103 with SMTP id al7mr1528847lbc.66.1439823815571;
Mon, 17 Aug 2015 08:03:35 -0700 (PDT)
MIME-Version: 1.0
References: <20150817100918.BD1F343128@smtp.hushmail.com>
<1439815244.89850.YahooMailBasic@web173102.mail.ir2.yahoo.com>
<20150817133438.DDD4243128@smtp.hushmail.com>
<64C86292-6671-4729-8A77-63C081797F62@gmail.com>
<CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
In-Reply-To: <CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
From: Levin Keller <post@levinkeller.de>
Date: Mon, 17 Aug 2015 15:03:25 +0000
Message-ID: <CAG86ZOyKcO_FBU4C_ghNuRfqLqB8ruivOtNajBs7whbR10xWPA@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>, Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2381811273d051d831b1f
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] Annoucing Not-BitcoinXT
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: Mon, 17 Aug 2015 15:03:39 -0000
--001a11c2381811273d051d831b1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Dear Eric,
thank you for sharing your thoughts.
It obviously boils down to political beliefs, not so much technical
arguments. I understand that you are in favor of a "guided
decentralization" and you are most happily invited to follow this path. I
don't want to be on it. I want total decentralisation of bitcoin and many
other parts of the current system.
So in the end the hard fork might be perfect, because people like you will
not waste so much more energy and time fighting people like me (and others)
who are following different dogmata because we are using different coins
and talking about different code. Interestingly enough in the end we will
probably have a winner - determined by the price - so I am looking forward
to the outcome. It is just the time so make some bets, which I embrace.
Another interesting thing is, that you actually fear problems arising from
this. What do you have to loose? Just stick with the old bitcoin version
and weather this storm. Bitcoin is not going to vanish or break from this.
It is just forking. One fork will come stronger out of this. You just have
to choose a side and live with it, if you loose it all. But that is the
story of bitcoin since the beginning. If you ask me, you fear the choice,
not the change.
Cheers
Levin
Adam Back via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> schrieb
am Mo., 17. Aug. 2015 um 16:37 Uhr:
> Thank you Eric for saying what needs to be said.
>
> Starting a fork war is just not constructive and there are multiple
> proposals being evaluated here.
>
> I think that one thing that is not being so much focussed on is
> Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
> Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
> SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
> the likely event that Bitcoin-XT results in a network-split.
>
> The recent proposal here to run noXT (patch to falsely claim to mine
> on XT while actually rejecting it's blocks) could add enough
> uncertainty about the activation that Bitcoin-XT would probably have
> to be aborted.
>
> Adam
>
> On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > NxtChg,
> >
> > In the entire history of Bitcoin we=E2=80=99ve never attempted anything=
even
> closely resembling a hard fork like what=E2=80=99s being proposed here.
> >
> > Many of us have wanted to push our own hard-forking changes to the
> protocol=E2=80=A6and have been frustrated because of the inability to do =
so.
> >
> > This inability is not due to any malice on anyone=E2=80=99s part=E2=80=
=A6it is a feature
> of Satoshi=E2=80=99s protocol. For better or worse, it is *very hard* to =
change the
> rules=E2=80=A6and this is exactly what imbues Bitcoin with one of its mos=
t powerful
> attributes: very well-defined settlement guarantees that cannot be sudden=
ly
> altered nor reversed by anyone.
> >
> > We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6and =
for the most part
> these changes have been pretty uncontroversial=E2=80=A6or at least, they =
have not
> had nearly the level of political divisiveness that this block size issue
> is having. And even then, we=E2=80=99ve encountered a number of problems =
with these
> deployments that have at times required goodwill cooperation between
> developers and mining pool operators to fix.
> >
> > Again, we have NEVER attempted anything even remotely like what=E2=80=
=99s being
> proposed - we=E2=80=99ve never done any sort of hard fork before like thi=
s. If even
> fairly uncontroversial soft forks have caused problems, can you imagine t=
he
> kinds of potential problems that a hard fork over some highly polarizing
> issue might raise? Do you really think people are going to want to
> cooperate?!?
> >
> > I can understand that some people would like bigger blocks. Other peopl=
e
> might want feature X, others feature Y=E2=80=A6and we can argue the merit=
s of this
> or that to death=E2=80=A6but the fact remains that we have NEVER attempte=
d any hard
> forking change=E2=80=A6not even with a simple, totally uncontroversial no=
-brainer
> improvement that would not risk any sort of ill-will that could hamper
> remedies were it not to go as smoothly as we like. *THIS* is the
> fundamental problem - the whole bigger block thing is a minor issue by
> comparison=E2=80=A6it could be any controversial change, really.
> >
> > Would you want to send your test pilots on their first flight=E2=80=A6t=
he first
> time an aircraft is ever flown=E2=80=A6directly into combat without havin=
g tested
> the plane? This is what attempting a hard fork mechanism that=E2=80=99s N=
EVER been
> done before in such a politically divisive environment basically amounts
> to=E2=80=A6but it=E2=80=99s even worse. We=E2=80=99re basically risking t=
he entire air force (not
> just one plane) over an argument regarding how many seats a plane should
> have that we=E2=80=99ve never flown before.
> >
> > We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other peop=
le=E2=80=99s money that
> is on the line here. Don=E2=80=99t we owe it to them to at least test out=
the
> system on a far less controversial, far less divisive change first to mak=
e
> sure we can even deploy it without things breaking? I don=E2=80=99t even =
care about
> the merits regarding bigger blocks vs. smaller blocks at this point, to b=
e
> quite honest - that=E2=80=99s such a petty thing compared to what I=E2=80=
=99m talking about
> here. If we attempt a novel hard-forking mechanism that=E2=80=99s NEVER b=
een
> attempted before (and which as many have pointed out is potentially fraug=
ht
> with serious problems) on such a politically divisive, polarizing issue,
> the result is each side will refuse to cooperate with the other out of
> spite=E2=80=A6and can easily lead to a war, tanking the value of everyone=
=E2=80=99s assets
> on both chains. All so we can process 8 times the number of transactions =
we
> currently do? Even if it were 100 times, we wouldn=E2=80=99t even come cl=
ose to
> touching big payment processors like Visa. It=E2=80=99s hard to imagine a=
protocol
> improvement that=E2=80=99s worth the risk.
> >
> > I urge you to at least try to see the bigger picture here=E2=80=A6and t=
o
> understand that nobody is trying to stop anyone from doing anything out o=
f
> some desire for maintaining control - NONE of us are able to deploy hard
> forks right now without facing these problems. And different people
> obviously have different priorities and preferences as to which of these
> changes would be best to do first. This whole XT thing is essentially
> giving *one* proposal special treatment above those that others have
> proposed. Many of us have only held back from doing this out of our belie=
f
> that goodwill amongst network participants is more important than trying =
to
> push some pet feature some of us want.
> >
> > Please stop this negativity - we ALL want the best for Bitcoin and are
> doing our best, given what we understand and know, to do what=E2=80=99s r=
ight.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11c2381811273d051d831b1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Dear Eric,<div><br></div><div>thank you for sharing your t=
houghts.</div><div><br></div><div>It obviously boils down to political beli=
efs, not so much technical arguments. I understand that you are in favor of=
a "guided decentralization" and you are most happily invited to =
follow this path. I don't want to be on it. I want total decentralisati=
on of bitcoin and many other parts of the current system.</div><div><br></d=
iv><div>So in the end the hard fork might be perfect, because people like y=
ou will not waste so much more energy and time fighting people like me (and=
others) who are following different dogmata because we are using different=
coins and talking about different code. Interestingly enough in the end we=
will probably have a winner - determined by the price - so I am looking fo=
rward to the outcome. It is just the time so make some bets, which I embrac=
e.</div><div><br></div><div>Another interesting thing is, that you actually=
fear problems arising from this. What do you have to loose? Just stick wit=
h the old bitcoin version and weather this storm. Bitcoin is not going to v=
anish or break from this. It is just forking. One fork will come stronger o=
ut of this. You just have to choose a side and live with it, if you loose i=
t all. But that is the story of bitcoin since the beginning. If you ask me,=
you fear the choice, not the change.</div><div><br></div><div>Cheers</div>=
<div><br></div><div>Levin</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">Adam Back via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> schrieb=
am Mo., 17. Aug. 2015 um 16:37=C2=A0Uhr:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">Thank you Eric for saying what needs to be said.<br>
<br>
Starting a fork war is just not constructive and there are multiple<br>
proposals being evaluated here.<br>
<br>
I think that one thing that is not being so much focussed on is<br>
Bitcoin-XT is both a hard-fork and a soft-fork.=C2=A0 It's a hard-fork =
on<br>
Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core<br>
SPV nodes that did not opt-in.=C2=A0 It exposes those SPV nodes to loss in<=
br>
the likely event that Bitcoin-XT results in a network-split.<br>
<br>
The recent proposal here to run noXT (patch to falsely claim to mine<br>
on XT while actually rejecting it's blocks) could add enough<br>
uncertainty about the activation that Bitcoin-XT would probably have<br>
to be aborted.<br>
<br>
Adam<br>
<br>
On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> NxtChg,<br>
><br>
> In the entire history of Bitcoin we=E2=80=99ve never attempted anythin=
g even closely resembling a hard fork like what=E2=80=99s being proposed he=
re.<br>
><br>
> Many of us have wanted to push our own hard-forking changes to the pro=
tocol=E2=80=A6and have been frustrated because of the inability to do so.<b=
r>
><br>
> This inability is not due to any malice on anyone=E2=80=99s part=E2=80=
=A6it is a feature of Satoshi=E2=80=99s protocol. For better or worse, it i=
s *very hard* to change the rules=E2=80=A6and this is exactly what imbues B=
itcoin with one of its most powerful attributes: very well-defined settleme=
nt guarantees that cannot be suddenly altered nor reversed by anyone.<br>
><br>
> We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6and=
for the most part these changes have been pretty uncontroversial=E2=80=A6o=
r at least, they have not had nearly the level of political divisiveness th=
at this block size issue is having. And even then, we=E2=80=99ve encountere=
d a number of problems with these deployments that have at times required g=
oodwill cooperation between developers and mining pool operators to fix.<br=
>
><br>
> Again, we have NEVER attempted anything even remotely like what=E2=80=
=99s being proposed - we=E2=80=99ve never done any sort of hard fork before=
like this. If even fairly uncontroversial soft forks have caused problems,=
can you imagine the kinds of potential problems that a hard fork over some=
highly polarizing issue might raise? Do you really think people are going =
to want to cooperate?!?<br>
><br>
> I can understand that some people would like bigger blocks. Other peop=
le might want feature X, others feature Y=E2=80=A6and we can argue the meri=
ts of this or that to death=E2=80=A6but the fact remains that we have NEVER=
attempted any hard forking change=E2=80=A6not even with a simple, totally =
uncontroversial no-brainer improvement that would not risk any sort of ill-=
will that could hamper remedies were it not to go as smoothly as we like. *=
THIS* is the fundamental problem - the whole bigger block thing is a minor =
issue by comparison=E2=80=A6it could be any controversial change, really.<b=
r>
><br>
> Would you want to send your test pilots on their first flight=E2=80=A6=
the first time an aircraft is ever flown=E2=80=A6directly into combat witho=
ut having tested the plane? This is what attempting a hard fork mechanism t=
hat=E2=80=99s NEVER been done before in such a politically divisive environ=
ment basically amounts to=E2=80=A6but it=E2=80=99s even worse. We=E2=80=99r=
e basically risking the entire air force (not just one plane) over an argum=
ent regarding how many seats a plane should have that we=E2=80=99ve never f=
lown before.<br>
><br>
> We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other peo=
ple=E2=80=99s money that is on the line here. Don=E2=80=99t we owe it to th=
em to at least test out the system on a far less controversial, far less di=
visive change first to make sure we can even deploy it without things break=
ing? I don=E2=80=99t even care about the merits regarding bigger blocks vs.=
smaller blocks at this point, to be quite honest - that=E2=80=99s such a p=
etty thing compared to what I=E2=80=99m talking about here. If we attempt a=
novel hard-forking mechanism that=E2=80=99s NEVER been attempted before (a=
nd which as many have pointed out is potentially fraught with serious probl=
ems) on such a politically divisive, polarizing issue, the result is each s=
ide will refuse to cooperate with the other out of spite=E2=80=A6and can ea=
sily lead to a war, tanking the value of everyone=E2=80=99s assets on both =
chains. All so we can process 8 times the number of transactions we current=
ly do? Even if it were 100 times, we wouldn=E2=80=99t even come close to to=
uching big payment processors like Visa. It=E2=80=99s hard to imagine a pro=
tocol improvement that=E2=80=99s worth the risk.<br>
><br>
> I urge you to at least try to see the bigger picture here=E2=80=A6and =
to understand that nobody is trying to stop anyone from doing anything out =
of some desire for maintaining control - NONE of us are able to deploy hard=
forks right now without facing these problems. And different people obviou=
sly have different priorities and preferences as to which of these changes =
would be best to do first. This whole XT thing is essentially giving *one* =
proposal special treatment above those that others have proposed. Many of u=
s have only held back from doing this out of our belief that goodwill among=
st network participants is more important than trying to push some pet feat=
ure some of us want.<br>
><br>
> Please stop this negativity - we ALL want the best for Bitcoin and are=
doing our best, given what we understand and know, to do what=E2=80=99s ri=
ght.<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>
</blockquote></div>
--001a11c2381811273d051d831b1f--
|