Peter R [ARCHIVE] on Nostr: š Original date posted:2015-08-31 š Original message:I agree, s7r, that Bitcoin ...
š
Original date posted:2015-08-31
š Original message: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 at 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 at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at 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 (
)
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/14b56b5b/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/14b56b5b/attachment.sig>;
š Original message: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 at 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 at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at 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 (
)> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/14b56b5b/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/14b56b5b/attachment.sig>;