[bitcoin-dev] BIP Classification Process

[bitcoin-dev] BIP Classification Process

[Eric Lombrozo]

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

Re: [bitcoin-dev] BIP Classification Process

[Btc Drak]

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

Re: [bitcoin-dev] BIP Classification Process

[Eric Lombrozo]

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

Codebase forks with nonconsensus features are totally fine! It’s the bitterness and resentment that arose out of the need to get everyone to agree on something that not everyone really needs to agree on that’s the problem.

> On Jan 28, 2016, at 11:21 PM, Btc Drak <btcdrak@gmail.com> wrote:
> 
> 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 <mailto: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 <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 <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 


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

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