Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9BA9E1512 for ; 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 ; 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 In-Reply-To: <55E4E7AA.6010905@sky-ip.org> Date: Mon, 31 Aug 2015 19:16:22 -0700 Message-Id: References: <602b978abcedd92fbed85f305d9d7bfe@cock.li> <55E4B8C9.5030606@openbitcoinprivacyproject.org> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > > > > 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
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.  

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.

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.

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.

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.

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.li= nuxfoundation.org
> <mailto:bitcoin-dev@l= ists.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
>


= --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--