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
|
Return-Path: <slashdevnull@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 519623EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 14:58:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from BLU004-OMC4S6.hotmail.com (blu004-omc4s6.hotmail.com
[65.55.111.145])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7B1FA1ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 14:58:42 +0000 (UTC)
Received: from BLU437-SMTP6 ([65.55.111.135]) by BLU004-OMC4S6.hotmail.com
over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);
Mon, 17 Aug 2015 07:58:41 -0700
X-TMN: [07TVmiz3gRaCe67CUNxQB5S1ylETb3xB]
X-Originating-Email: [slashdevnull@hotmail.com]
Message-ID: <BLU437-SMTP6520F38414718F4E15E0DC6790@phx.gbl>
User-Agent: Microsoft-MacOutlook/14.4.9.150325
Date: Mon, 17 Aug 2015 22:58:22 +0800
From: GC <slashdevnull@hotmail.com>
To: Adam Back <adam@cypherspace.org>,
Eric Lombrozo <elombrozo@gmail.com>
Thread-Topic: [bitcoin-dev] Annoucing Not-BitcoinXT
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 17 Aug 2015 14:58:40.0851 (UTC)
FILETIME=[343D6A30:01D0D8FD]
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD 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:58:43 -0000
Adam,
While greatly appreciating your prior efforts in crypto-ccy R&D and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like =B3attack=B2, =B3fork war" and throwing so much FUD
into the developer email channel directly after Eric=B9s email.
We would appreciate seeing your well-argued thoughts, not FUD and flaming.
There are multitudes of trolls in all forums already.
On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>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=B9ve never attempted anything even
>>closely resembling a hard fork like what=B9s being proposed here.
>>
>> Many of us have wanted to push our own hard-forking changes to the
>>protocol=8Aand have been frustrated because of the inability to do so.
>>
>> This inability is not due to any malice on anyone=B9s part=8Ait is a
>>feature of Satoshi=B9s protocol. For better or worse, it is *very hard* to
>>change the rules=8Aand this is exactly what imbues Bitcoin with one of its
>>most powerful attributes: very well-defined settlement guarantees that
>>cannot be suddenly altered nor reversed by anyone.
>>
>> We=B9ve managed to have a few soft forks in the past=8Aand for the most
>>part these changes have been pretty uncontroversial=8Aor at least, they
>>have not had nearly the level of political divisiveness that this block
>>size issue is having. And even then, we=B9ve 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=B9s being
>>proposed - we=B9ve 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?!?
>>
>> I can understand that some people would like bigger blocks. Other
>>people might want feature X, others feature Y=8Aand we can argue the
>>merits of this or that to death=8Abut the fact remains that we have NEVER
>>attempted any hard forking change=8Anot 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=8Ait could be any controversial change,
>>really.
>>
>> Would you want to send your test pilots on their first flight=8Athe first
>>time an aircraft is ever flown=8Adirectly into combat without having
>>tested the plane? This is what attempting a hard fork mechanism that=B9s
>>NEVER been done before in such a politically divisive environment
>>basically amounts to=8Abut it=B9s even worse. We=B9re basically risking the
>>entire air force (not just one plane) over an argument regarding how
>>many seats a plane should have that we=B9ve never flown before.
>>
>> We=B9re talking billlions of dollars=B9 worth of other people=B9s money that
>>is on the line here. Don=B9t we owe it to them to at least test out the
>>system on a far less controversial, far less divisive change first to
>>make sure we can even deploy it without things breaking? I don=B9t even
>>care about the merits regarding bigger blocks vs. smaller blocks at this
>>point, to be quite honest - that=B9s such a petty thing compared to what
>>I=B9m talking about here. If we attempt a novel hard-forking mechanism
>>that=B9s 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=8Aand can easily lead to a war,
>>tanking the value of everyone=B9s 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=B9t even come close to touching big payment
>>processors like Visa. It=B9s hard to imagine a protocol improvement that=B9s
>>worth the risk.
>>
>> I urge you to at least try to see the bigger picture here=8Aand 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
>>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
>>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
>>doing our best, given what we understand and know, to do what=B9s right.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
