Eric Lombrozo [ARCHIVE] on Nostr: đź“… Original date posted:2016-01-29 đź“ť Original message:Codebase forks with ...
đź“… Original date posted:2016-01-29
📝 Original message: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 at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.sig>;
📝 Original message: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 at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.sig>;