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
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9BA9E1512
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 02:16:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3012314B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 02:16:27 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx102)
with ESMTPSA (Nemesis) id 0MVayZ-1ZC5YA2ZGZ-00YyTx;
Tue, 01 Sep 2015 04:16:22 +0200
Content-Type: multipart/signed;
boundary="Apple-Mail=_3249B38A-6A43-4129-B023-2426BB90E755";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <55E4E7AA.6010905@sky-ip.org>
Date: Mon, 31 Aug 2015 19:16:22 -0700
Message-Id: <CC252814-9AF6-4A28-926E-EE83C517E440@gmx.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>
To: s7r@sky-ip.org
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:bIunYGW6RTxYEBMzivAksIjkI3drSK6k6g84BaqFHY35gafnMVs
3JJkksKzFu+AozNNAFvPp99CJZy1dzMg/jR++meR2uBWDht0KCzfH1C8Jhpfi8F8XpLGZ+7
YJq8j5Afy8ACcAEeHHPjDzmtXyQN6W+ttO8WC/Rb0T3cynFR1depzePUjnOMDEgKRviA1uR
/6uHfhftx87RZFs6SoXwQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:JdIi/qefaHo=:RTbIMyeE3PBK1IMHqUaS34
y9vyMbWyX4aAvrD28vMtVDvU6cESKwZPBub7ag6o1QrzBockqCCPrxx5S2fwq0Kiv9NrDH8yA
0S2UaFupMUNEIxP4IVHDHSlZsJPldzMJEBOdfEpvuX9eD+WB328f8JrbGxz6363Td3FDkKA1x
sjO6WliV62Y9KuUR3Cwah52IiDm8IkY8GcOWl9DKGWhqeTHMi+xO3FTJGx6u10zYI3a5WpNNy
oyFukrQFIsg70nuGsR9m86+Ic/9B2FL2QtT9BqHsMR5ENePjRgwZfLUkU7yXbrjtKpJzvFg13
ls5dfqhU47XawSMirSLcz+C3lLTgqAvasIX3HzwZI4/FIab0IqZx8G0AcZbajvdQhXjSnK5cl
ZL7G+an1Uu1lwnStLjVLhhGJ/OyVhdK81hH9DP1rNxgPVx3P8VQG9UKcpMufsS+8RBCdYIvTi
YehIY/5XT9d4h6iljf75iumc8k5LEc0OyuomzfmbMZRMHHVnsD+AkFhPaVgzXhVRAH7alOBEJ
bGvJ2MEgQJX/y4z8flQ12x9sIKmT55RfEndi315XA5J+1vXvlZ3+gtkDk7m5O6ksF9FreMMJ7
4K5jc/olLuX1yAf8ZbBfVb9qxctM6641gzYWxtzQcBLGqYUUCI6WYl85bCIiDSnnuK+M72dN1
cvh2x1uoIAJcwmL9QLhaMsKkdWo28/G6Q/zg1lIAxFUpNyZ7k2/xjQHAgOXbKpXt/ebCINjKl
yKqyBXQCePF5VPZ+z7xMrwv8pwAUrHwtPX22KXrGkwrjvy64gE8kJF1KCwq087VXVZuPriGEj
Uc5OwVd6SVLGFlgI3W2U3LfWSpU0w==
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [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 02:16:32 -0000
--Apple-Mail=_3249B38A-6A43-4129-B023-2426BB90E755
Content-Type: multipart/alternative;
boundary="Apple-Mail=_1DEB796C-DFFA-40A7-A5C6-7C23E13B2E26"
--Apple-Mail=_1DEB796C-DFFA-40A7-A5C6-7C23E13B2E26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
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. =20
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. =20
This is the decentralized spirit of Bitcoin in action. Creative =
destruction. Consensus formed simply by the code that gets run. =20
Let's kill Bitcoin Core and allow the green shoots of a garden of new =
implementations to grow from its fertile ashes. =20
Sincerely,
Peter R
On 2015-08-31, at 4:47 PM, s7r <s7r@sky-ip.org> wrote:
> Signed PGP part
> Decentralization depends on the context and does not have a definition
> in a form that it was demanded... I can confirm we have people in our
> community which do understand decentralization, and quite good
> actually, just there is no definition if the form demanded.
>=20
> It is known that ~90% (at least of the nodes accepting incoming
> connections) are running Bitcoin Core software. This does not mean
> that Bitcoin is somehow less decentralized. Bitcoin Core is open
> source, it has many contributors from all over the world and there are
> many pull requests - most of them do get merged if you check the
> commit history. It is widely used because the quality of the code is 5
> stars. There are other implementations as well, they are just not
> widely used. This does not mean one is not free to write his own
> implementation of the Bitcoin protocol (assuming he follows the
> consensus rules of the network). The biggest problem is convincing
> users to adopt that implementation, which is a normal thing which
> happens in general, not only related to software implementations.
>=20
> The problem is there is no other implementation out there which comes
> near the quality of the code in Bitcoin Core. I am actually eager to
> try other implementations as well, but something serious, because
> Bitcoin itself is a payment protocol not something to play with.
>=20
> This is the reason why a lot of developers contribute to Bitcoin Core
> rather than writing their own implementation. This only makes Bitcoin
> Core stronger, better, and obviously the result is that it has
> majority in the ecosystem for good reasons. If I'm experienced in a
> certain segment related to software developing, I am better of in
> contributing to Bitcoin Core just with the part I know instead of
> writing from scratch my own implementation.
>=20
> On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote:
> > On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >> Even so, *decentralization is a means to an end* - not an
> >> end-goal. It is essential for Bitcoin to be a useful alternative,
> >> of course.
> >
> > I agree. What about decentralization in development? Gavin
> > recently said that he wants to "get to the point where there will
> > be multiple robust implementations of the core protocol."
> >
> > When I look at this image (https://i.imgur.com/zivHJvY.gif)
> > illustrating centralization in nodes, mining and development, the
> > biggest source of concern for me is the 85% node share around
> > Bitcoin Core. With this level of centralization, it may be
> > possible in the future for a group of coders to prevent important
> > changes from being made in a timely fashion (e.g., should their
> > interests no longer align with those of the larger Bitcoin
> > community).
> >
> > It is my opinion, then, that we should support multiple
> > implementations of the Bitcoin protocol, working to reduce the
> > network's dependency on Core.
> >
> > Best regards, Peter R
> >
>=20
--Apple-Mail=_1DEB796C-DFFA-40A7-A5C6-7C23E13B2E26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" =
content=3D"text/html charset=3Dwindows-1252"></head><body =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>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:</div><div><br></div><div>- =
Bitcoin-A (XT)</div><div>- Bitcoin-B (Blockstream)</div><div>- Bitcoin-C =
(promoting BIP100)</div><div>- Bitcoin-D</div><div>- =
etc.</div><div><br></div><div>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. =
</div><div><br></div><div>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, <b>I suggest we work =
together to never reach consensus with Bitcoin Core. </b>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. =
</div><div><br></div><div>This is the decentralized spirit of =
Bitcoin in action. Creative destruction. Consensus formed =
simply by the code that gets run. =
</div><div><br></div><div><b>Let's kill Bitcoin Core and allow the =
green shoots of a garden of new implementations to grow from =
its fertile =
ashes. </b></div><div><br></div><div>Sincerely,</div><div>Peter=
R</div><div><br></div><br><div><div>On 2015-08-31, at 4:47 PM, s7r =
<<a href=3D"mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><fieldset style=3D"padding-top:10px; border:0px; border: =
3px solid #CCC; padding-left: 20px;"><legend =
style=3D"font-weight:bold">Signed PGP part</legend><div =
style=3D"padding-left:3px;">Decentralization depends on the context and =
does not have a definition<br>in a form that it was demanded... I can =
confirm we have people in our<br>community which do understand =
decentralization, and quite good<br>actually, just there is no =
definition if the form demanded.<br><br>It is known that ~90% (at least =
of the nodes accepting incoming<br>connections) are running Bitcoin Core =
software. This does not mean<br>that Bitcoin is somehow less =
decentralized. Bitcoin Core is open<br>source, it has many contributors =
from all over the world and there are<br>many pull requests - most of =
them do get merged if you check the<br>commit history. It is widely used =
because the quality of the code is 5<br>stars. There are other =
implementations as well, they are just not<br>widely used. This does not =
mean one is not free to write his own<br>implementation of the Bitcoin =
protocol (assuming he follows the<br>consensus rules of the network). =
The biggest problem is convincing<br>users to adopt that implementation, =
which is a normal thing which<br>happens in general, not only related to =
software implementations.<br><br>The problem is there is no other =
implementation out there which comes<br>near the quality of the code in =
Bitcoin Core. I am actually eager to<br>try other implementations as =
well, but something serious, because<br>Bitcoin itself is a payment =
protocol not something to play with.<br><br>This is the reason why a lot =
of developers contribute to Bitcoin Core<br>rather than writing their =
own implementation. This only makes Bitcoin<br>Core stronger, better, =
and obviously the result is that it has<br>majority in the ecosystem for =
good reasons. If I'm experienced in a<br>certain segment related to =
software developing, I am better of in<br>contributing to Bitcoin Core =
just with the part I know instead of<br>writing from scratch my own =
implementation.<br><br>On 9/1/2015 2:32 AM, Peter R via bitcoin-dev =
wrote:<br>> On 2015-08-31, at 2:24 PM, Allen Piscitello via =
bitcoin-dev<br>> <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>> <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">mailto:bitcoin-dev@l=
ists.linuxfoundation.org</a>>> wrote:<br>><br>>> Even so, =
*decentralization is a means to an end* - not an<br>>> end-goal. =
It is essential for Bitcoin to be a useful alternative,<br>>> of =
course.<br>><br>> I agree.<span =
class=3D"Apple-converted-space"> </span> What about =
decentralization in development?<span =
class=3D"Apple-converted-space"> </span> Gavin<br>> recently =
said that he wants to "get to the point where there will<br>> be =
multiple robust implementations of the core protocol."<br>><br>> =
When I look at this image (<a =
href=3D"https://i.imgur.com/zivHJvY.gif">https://i.imgur.com/zivHJvY.gif</=
a>)<br>> illustrating centralization in nodes, mining and =
development, the<br>> biggest source of concern for me is the 85% =
node share around<br>> Bitcoin Core.<span =
class=3D"Apple-converted-space"> </span> With this level of =
centralization, it may be<br>> possible in the future for a group of =
coders to prevent important<br>> changes from being made in a timely =
fashion (e.g., should their<br>> interests no longer align with those =
of the larger Bitcoin<br>> community).<br>><br>> It is my =
opinion, then, that we should support multiple<br>> implementations =
of the Bitcoin protocol, working to reduce the<br>> network's =
dependency on Core.<br>><br>> Best regards, Peter =
R<br>></div></fieldset><br></blockquote></div><br></body></html>=
--Apple-Mail=_1DEB796C-DFFA-40A7-A5C6-7C23E13B2E26--
--Apple-Mail=_3249B38A-6A43-4129-B023-2426BB90E755
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJV5Qp2AAoJEORK3dmodztxcjYH/jQbSxSOv/jVRUfGrYtQkpDx
meiV71LMoDgfzLctZrg1njdVFDii893p095AXSldgAdawJQHMbEauKiyZzSOSCsn
+SjRIhIO+Ryf8Y9dcVO3aIZ2i041rO5SN6kCagvPMvSSqS1oixLl4wr++79rl2ml
two70Y+fYo3SMDZsuQ3VMFk5LuHQWECx1OrCA+GsRwlkmNFXfkwQpDX+3D+oHNc9
GWgeYOwM/Gb9fa+JMqO0VM6evZfSeIl7WeqLEsNzwaoTXpGMBUaGaF9NzGGl9x61
XMBShLGS+EFvde4VDCLfMHL0X+Ub4kzCD0nkv4fo971AOrBOJHMEM7s+bToMtus=
=8H1T
-----END PGP SIGNATURE-----
--Apple-Mail=_3249B38A-6A43-4129-B023-2426BB90E755--
|
