Re: [bitcoin-dev] BIP Classification Process

From: Btc Drak <btcdrak@gmail•com>
To: Eric Lombrozo <elombrozo@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Classification Process
Date: Fri, 29 Jan 2016 07:21:10 +0000	[thread overview]
Message-ID: <CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com> (raw)
In-Reply-To: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

Your proposal does not solve the issue related to Mike creating his own
fork. He created his own for because he had a non-consensus feature set
that Bitcoin Core disagreed with and he wanted. That is to be _encouraged_.
I also maintain my own Bitcoin fork with a specific (non-consensus) feature
for the same reason and I am perfectly happy with the arrangement, as are
my userbase.

Classification of BIPs is fine, I have no problem with that and I support
your BIP, but your proposition it would have stopped Mike from creating his
own distribution is false (nor desirable): it was down to a strong
differing of technical opinions between Mike and a dozen other developers
as well as node security concerns (which were proved correct).

On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Folks,
>
> I think the current situation with forks could have been avoided with a
> better process that can distinguish between different layers for bitcoin
> modification proposals.
>
> For instance, BIP64 was proposed by Mike Hearn, which does not affect the
> consensus layer at all. Many Core devs disliked the proposal and Mike had
> lots of pushback. Regardless of whether or not you agree with the merits of
> Mike’s ideas here, fact is having nodes that support BIP64 would not
> fundamentally break the Bitcoin network.
>
> This issue prompted Mike to break off from Core and create XT as the
> applications he was developing required BIP64 to work. With this split,
> Gavin found a new home for his big block ideas…and the two teamed up.
>
> We need to have a process that clearly distinguishes these different
> layers and allows much more freedom in the upper layers while requiring
> agreement at the consensus layer. Many of these fork proposals are actually
> conflating different features, only some of which would actually be
> consensus layer changes. When people proposing nonconsensus features get
> pushback from Core developers they feel rejected and are likely to team up
> with others trying to push for hard forks and the like.
>
> A while back I had submitted a BIP -  BIP123 - that addresses this issue.
> I have updated it to include all the currently proposed and accepted BIPs
> and have submitted a PR: https://github.com/bitcoin/bips/pull/311
>
> I urge everyone to seriously consider getting this BIP accepted as a top
> priority before we get more projects all trying their hand at stuff and not
> understanding these critical distinctions.
>
>
> - Eric
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3560 bytes --]