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
|
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 EEB267AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 14:36:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 539701BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 14:36:50 +0000 (UTC)
Received: from mail-ig0-f181.google.com ([209.85.213.181]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0LlXVp-1YtOI20vJ9-00bNaw for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 16:36:49 +0200
Received: by igfj19 with SMTP id j19so56789718igf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.50.175 with SMTP id d15mr16873943igo.18.1439822208626;
Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
Received: by 10.50.104.198 with HTTP; Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
In-Reply-To: <64C86292-6671-4729-8A77-63C081797F62@gmail.com>
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>
Date: Mon, 17 Aug 2015 15:36:48 +0100
Message-ID: <CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:95XvfTwdJauS0ykpMMJSGRpGMZ4Sl3q8OtAg8rh9xgPkO9Sl8Q3
0frZ7oEBPraGPWUXUveOcO9ZvYstWZ2rjuB0Gy0dRRFkebT8vxoNcbLb1DTkXRDLm29zv7X
iHfpb+hvnV74qfLkFwC83BkS3cqAJRBmOCKer9aQha+QfZ2cGqwlAWdW7VY9fChdjP7Emxj
kRynpPxUttBxeHlIj0YMQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:RZ1wiXbnl0E=:o/O2rLYB8bh8Q7dF3d6r2A
OeXxXTPgzndbeIoy7Petu+Jh7oVSApAc1x992OyboVORmqDpi5+lwtyAk7gfDX5Vq8+TDjay2
unx64iRp/xVoDxMzNCFGSHuJ9YfMFnX+Ni6rnkpKKuqj/Nii/Zu2Wd8rqMqyAZDCZU+PDDPwl
8EdKZ/E/rfdu9d4B25rTQnTJ/eDLaHAMe5uVx7QhGwU0cwc14Kt2RQN6Sn/8vhBCTF8AgVjpx
ZKghgsGsfgmwh9saWP7XaFx9xa3lbUa38s4pAbMDWk8CgT+epiS3i3FqsOo0uiuZSCiDx5Z5d
rA0umWVKiy/GUgG1Ws6HTcSDoe99wVfrkDYxJ8RA1HMvdwMFxANZuVBszg8kd8zOJVrqjUz6S
I7GOxcVEsmUyTROtoXIMMMNhY2VsIcZKbJT9ACqJRTDuNcky1qO82svDg4baU8pbBONvDLK9B
KMtzUJ25AFSsbC+nlH/FkLLe0zbXbDfgLfD+Hw6MbB22sVTpn0MmtR1RoBDtkrnEWKMC9NvWa
qlpyzGKZb/uRywv7ZWYAT/i0Ga1GzLgkoOeSqAX3h5YaNERTXBfvps5Jwz3h4ZLDLVqWy1IM6
edq0fCCuesvAueT0ZEUOvpuU+z0eeZ4U5Spf2obkDU6JP4IRpWmKvLrHNFQCtaMo+GAsI1Ptd
IS+VHxaw4Vah7TaQIlvphNdCZj4IzCskSi5LLPqpNGRa3o08dho69AbGM1N0xj/VOlkBGJGsU
XHy19ikuFXvwZqOX
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 14:36:52 -0000
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 e=
ven 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 protoc=
ol=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=A6=
it 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 Bitc=
oin with one of its most powerful attributes: very well-defined settlement =
guarantees that cannot be suddenly altered nor reversed by anyone.
>
> We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6and fo=
r the most part these changes have been pretty uncontroversial=E2=80=A6or a=
t 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 good=
will 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 lik=
e this. If even fairly uncontroversial soft forks have caused problems, can=
you imagine the kinds of potential problems that a hard fork over some hig=
hly polarizing issue might raise? Do you really think people are going to w=
ant to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people =
might want feature X, others feature Y=E2=80=A6and we can argue the merits =
of this or that to death=E2=80=A6but the fact remains that we have NEVER at=
tempted any hard forking change=E2=80=A6not even with a simple, totally unc=
ontroversial no-brainer improvement that would not risk any sort of ill-wil=
l that could hamper remedies were it not to go as smoothly as we like. *THI=
S* is the fundamental problem - the whole bigger block thing is a minor iss=
ue 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=A6the=
first time an aircraft is ever flown=E2=80=A6directly into combat without =
having tested the plane? This is what attempting a hard fork mechanism that=
=E2=80=99s NEVER been done before in such a politically divisive environmen=
t basically amounts to=E2=80=A6but it=E2=80=99s even worse. We=E2=80=99re b=
asically risking the entire air force (not just one plane) over an argument=
regarding how many seats a plane should have that we=E2=80=99ve never flow=
n before.
>
> We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other people=
=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 divis=
ive change first to make sure we can even deploy it without things breaking=
? I don=E2=80=99t even care about the merits regarding bigger blocks vs. sm=
aller blocks at this point, to be quite honest - that=E2=80=99s such a pett=
y thing compared to what I=E2=80=99m talking about here. If we attempt a no=
vel hard-forking mechanism that=E2=80=99s NEVER been attempted before (and =
which as many have pointed out is potentially fraught 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 easil=
y lead to a war, tanking the value of everyone=E2=80=99s assets on both cha=
ins. 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 close to touch=
ing big payment processors like Visa. It=E2=80=99s hard to imagine a protoc=
ol improvement that=E2=80=99s worth the risk.
>
> 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 fo=
rks right now without facing these problems. And different people obviously=
have different priorities and preferences as to which of these changes wou=
ld be best to do first. This whole XT thing is essentially giving *one* pro=
posal special treatment above those that others have proposed. Many of us h=
ave only held back from doing this out of our belief 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 do=
ing our best, given what we understand and know, to do what=E2=80=99s right=
.
|
