public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Lombrozo <elombrozo@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP Classification Process
Date: Thu, 28 Jan 2016 16:52:53 -0800	[thread overview]
Message-ID: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1694 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2302 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

             reply	other threads:[~2016-01-29  0:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  0:52 Eric Lombrozo [this message]
2016-01-29  7:21 ` Btc Drak
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=42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com \
    --to=elombrozo@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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