public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2016-01-29  7:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  0:52 [bitcoin-dev] BIP Classification Process Eric Lombrozo
2016-01-29  7:21 ` Btc Drak [this message]
2016-01-29  7:57   ` Eric Lombrozo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com' \
    --to=btcdrak@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox