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