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
|
Return-Path: <chrisjdcosta@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F1B3CF24
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 10:16:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB2A41C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 10:16:04 +0000 (UTC)
Received: by igboj15 with SMTP id oj15so52320131igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 03:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=aQJry3Vd+7tuifcJSugjVUdH1ZU2oVx+THA9bJ388aM=;
b=txAsSO1AoNd8oATN1cwasGA5/jOX27DiCjmchloUTweySQXsBC/ETlAEWNHMUt4GZL
9zfPhHUDK+TqGrOdrci5zt/j7I0sJPX81zfR9b9IImbOGhD8620CsSAP1RCU4dunbdrx
NfnDYmN6ziGnUq/CTds06/Odvd9UCXQiWSpH46qw5px218ocfPdt1H+7eO3N8xbnWqhY
C1tXOl1G5GvNSAGf4vG2HxdLcBERl0sw3N03CeQEZKLQxU81eKEdo1OwJXb6d9+cKtJ/
KmvBe/nrhvMDnCbjvdkR7rGYvuwaf4jRflZCzq9hHNKv/q5UvYAgBHcsGP5/WRQq33l3
JBkw==
MIME-Version: 1.0
X-Received: by 10.50.114.193 with SMTP id ji1mr1444800igb.97.1441102564185;
Tue, 01 Sep 2015 03:16:04 -0700 (PDT)
Sender: chrisjdcosta@gmail.com
Received: by 10.79.38.216 with HTTP; Tue, 1 Sep 2015 03:16:04 -0700 (PDT)
In-Reply-To: <CALqxMTFKDmQnFZimJPttyDdyOHbc_ffs-vV7XDwwJLLu=UPVfA@mail.gmail.com>
References: <602b978abcedd92fbed85f305d9d7bfe@cock.li>
<55E4B8C9.5030606@openbitcoinprivacyproject.org>
<e786da226b8e9cfaad335454b299ffd5@cock.li>
<CAJfRnm4kwHkBLUUOmfzViUwsdAf3LYSTruvHw9+-RbgxSMHLRg@mail.gmail.com>
<5A3D7824-F1E3-421B-A32A-0EF21DD215BD@gmx.com>
<55E4E7AA.6010905@sky-ip.org>
<CC252814-9AF6-4A28-926E-EE83C517E440@gmx.com>
<CALqxMTFKDmQnFZimJPttyDdyOHbc_ffs-vV7XDwwJLLu=UPVfA@mail.gmail.com>
Date: Tue, 1 Sep 2015 12:16:04 +0200
X-Google-Sender-Auth: K0pLC6pvEqamxjrkAxa6vo93TfM
Message-ID: <CAC0TF=mL1RpN5Gt75mYrVppe4gqUaK9VTHFR9uZq8N5FXv-nTQ@mail.gmail.com>
From: "Chris D'Costa" <chris.dcosta@meek.io>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e0122a32e6c5bd4051eacd687
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,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] Let's kill Bitcoin Core and allow the green
shoots of a garden of new implementations to grow from its fertile ashes
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, 01 Sep 2015 10:16:06 -0000
--089e0122a32e6c5bd4051eacd687
Content-Type: text/plain; charset=UTF-8
I think the "Kill King Bitcoin - Long Live the King" call is somewhat
inevitable, and we should expect this to happen from time-to-time, now that
the cat is out of the bag.
However, I fully agree with Adam that livenet is probably not the place to
play this game, and I'm also not convinced that testnet is either.
I often wondered if there is any appetite for a no-holds-barred, anything
goes, bitcoin fork that would allow for the kind of valuable
experimentation that Peter R is suggesting? This is a different concept
than an alt-coin because it would be undoubtedly unstable until consensus
is reached - and that is the whole idea. It hopefully would inform future
decisions about what gets rolled into Core. One problem I see with doing
this, is the lack of incentive.
Chris
On 1 September 2015 at 10:42, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Peter this seems to be a not well thought through course of action,
> fun though it maybe informally or philosophically or to tweak various
> peoples sensibilities.
>
> Bitcoin is a consensus system that does not work if there are
> incompatible versions of consensus code competing on the network.
> This is why work is underway on libconsensus so we can see diversity
> of implementation without the risk of incompatibility arising by
> software defect. It has proven quite hard to match independent
> consensus implementations bit for bit against an adaptive adversary
> looking for inconsistencies in interpretation.
>
> In terms of protocol updates it is more constructive therefore that
> people with a technical interest analyse and validate others proposals
> via testing, or make their own proposals so that we can arrive at a
> well validated upgrade mechanism that everyone upgrades to in a
> coordinated fashion.
>
> Previous intentional upgrades to bitcoin have been
> backwards-compatible (via soft-fork which can be secured reasonably
> using a miner vote trigger and temporary SPV security for those who
> not yet upgraded) but the current topic of a throughput increase is
> non-backwards-compatible (via a hard-fork), and the way to minimise
> risk of such an upgrade is for everyone to try to upgrade well in
> advance of an agreed upgrade schedule, and to be all upgrading to the
> *same* consensus rule change.
>
> Encouraging nodes or miners to "vote" by running a range of different
> consensus rules isnt really constructive I feel - it alarms people who
> understand the risks, sets things on a path that have to be fixed
> while in flight by obvious implication, and isnt collaborative - so it
> risks being a politicising suggestion on what should be a purely
> technical topic of choosing the best approach, where it is best to
> strive to keep things non-emotive and professional and technically
> focussed. Such calls are offending the technical sensibilities of
> people who understand the risks.
>
> Anyway lets try to keep things constructive and focus on analysing
> proposals.
>
> Adam
>
> On 31 August 2015 at 19:16, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I agree, s7r, that Bitcoin Core represents the most stable code base. To
> > create multiple implementations, other groups would fork Bitcoin Core
> > similar to what Bitcoin XT did. We could have:
> >
> > - Bitcoin-A (XT)
> > - Bitcoin-B (Blockstream)
> > - Bitcoin-C (promoting BIP100)
> > - Bitcoin-D
> > - etc.
> >
> > Innovation from any development group would be freely integrated by any
> > other development group, if desired. Of course, each group would have a
> > very strong incentive to remain fork-wise compatible with the other
> > implementations.
> >
> > In fact, this just gave me a great idea! Since Wladimir has stated that
> he
> > will not integrate a forking change into Core without Core Dev
> consensus, I
> > suggest we work together to never reach consensus with Bitcoin Core.
> This
> > will provide impetus for new implementations to fork from Core (like XT
> did)
> > and implement whatever scaling solution they deem best. The users will
> then
> > select the winning solution simply based on the code they choose to run.
> > The other implementations will then rush to make compatible changes in
> order
> > to keep their dwindling user bases.
> >
> > This is the decentralized spirit of Bitcoin in action. Creative
> > destruction. Consensus formed simply by the code that gets run.
> >
> > Let's kill Bitcoin Core and allow the green shoots of a garden of new
> > implementations to grow from its fertile ashes.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e0122a32e6c5bd4051eacd687
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think the "Kill King Bitcoin - Long Live the King&q=
uot; call is somewhat inevitable, and we should expect this to happen from =
time-to-time, now that the cat is out of the bag.=C2=A0<div><br></div><div>=
However, I fully agree with Adam that livenet is probably not the place to =
play this game, and I'm also not convinced that testnet is either.=C2=
=A0</div><div><br></div><div>I often wondered if there is any appetite for =
a no-holds-barred, anything goes, bitcoin fork that would allow for the kin=
d of valuable experimentation that Peter R is suggesting? This is a differe=
nt concept than an alt-coin because it would be undoubtedly unstable until =
consensus is reached - and that is the whole idea. It hopefully would infor=
m future decisions about what gets rolled into Core. One problem I see with=
doing this, is the lack of incentive.</div><div><br></div><div>Chris</div>=
<div class=3D"gmail_extra"><div><div class=3D"gmail_signature"><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br></div></div></div=
></div></div></div></div></div><div class=3D"gmail_quote">On 1 September 20=
15 at 10:42, Adam Back via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">Peter this seems to be a not well thought through course of action,<br=
>
fun though it maybe informally or philosophically or to tweak various<br>
peoples sensibilities.<br>
<br>
Bitcoin is a consensus system that does not work if there are<br>
incompatible versions of consensus code competing on the network.<br>
This is why work is underway on libconsensus so we can see diversity<br>
of implementation without the risk of incompatibility arising by<br>
software defect.=C2=A0 It has proven quite hard to match independent<br>
consensus implementations bit for bit against an adaptive adversary<br>
looking for inconsistencies in interpretation.<br>
<br>
In terms of protocol updates it is more constructive therefore that<br>
people with a technical interest analyse and validate others proposals<br>
via testing, or make their own proposals so that we can arrive at a<br>
well validated upgrade mechanism that everyone upgrades to in a<br>
coordinated fashion.<br>
<br>
Previous intentional upgrades to bitcoin have been<br>
backwards-compatible (via soft-fork which can be secured reasonably<br>
using a miner vote trigger and temporary SPV security for those who<br>
not yet upgraded) but the current topic of a throughput increase is<br>
non-backwards-compatible (via a hard-fork), and the way to minimise<br>
risk of such an upgrade is for everyone to try to upgrade well in<br>
advance of an agreed upgrade schedule, and to be all upgrading to the<br>
*same* consensus rule change.<br>
<br>
Encouraging nodes or miners to "vote" by running a range of diffe=
rent<br>
consensus rules isnt really constructive I feel - it alarms people who<br>
understand the risks, sets things on a path that have to be fixed<br>
while in flight by obvious implication, and isnt collaborative - so it<br>
risks being a politicising suggestion on what should be a purely<br>
technical topic of choosing the best approach, where it is best to<br>
strive to keep things non-emotive and professional and technically<br>
focussed.=C2=A0 Such calls are offending the technical sensibilities of<br>
people who understand the risks.<br>
<br>
Anyway lets try to keep things constructive and focus on analysing proposal=
s.<br>
<br>
Adam<br>
<br>
On 31 August 2015 at 19:16, Peter R via bitcoin-dev<br>
<div class=3D"HOEnZb"><div class=3D"h5"><<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wro=
te:<br>
> I agree, s7r, that Bitcoin Core represents the most stable code base.=
=C2=A0 To<br>
> create multiple implementations, other groups would fork Bitcoin Core<=
br>
> similar to what Bitcoin XT did.=C2=A0 We could have:<br>
><br>
> - Bitcoin-A (XT)<br>
> - Bitcoin-B (Blockstream)<br>
> - Bitcoin-C (promoting BIP100)<br>
> - Bitcoin-D<br>
> - etc.<br>
><br>
> Innovation from any development group would be freely integrated by an=
y<br>
> other development group, if desired.=C2=A0 Of course, each group would=
have a<br>
> very strong incentive to remain fork-wise compatible with the other<br=
>
> implementations.<br>
><br>
> In fact, this just gave me a great idea!=C2=A0 Since Wladimir has stat=
ed that he<br>
> will not integrate a forking change into Core without Core Dev consens=
us, I<br>
> suggest we work together to never reach consensus with Bitcoin Core.=
=C2=A0 This<br>
> will provide impetus for new implementations to fork from Core (like X=
T did)<br>
> and implement whatever scaling solution they deem best.=C2=A0 The user=
s will then<br>
> select the winning solution simply based on the code they choose to ru=
n.<br>
> The other implementations will then rush to make compatible changes in=
order<br>
> to keep their dwindling user bases.<br>
><br>
> This is the decentralized spirit of Bitcoin in action.=C2=A0 Creative<=
br>
> destruction.=C2=A0 Consensus formed simply by the code that gets run.<=
br>
><br>
> Let's kill Bitcoin Core and allow the green shoots of a garden of =
new<br>
> implementations to grow from its fertile ashes.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">_______________________=
________________________<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>
</div></div></blockquote></div><br></div></div>
--089e0122a32e6c5bd4051eacd687--
|
