đź“… 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>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:48:15
in reply to nevent1q…xk49
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:48:15Event JSON
{
"id": "06fbeaa436cab463ee7bcbfff47ffbb4d58ae9d1b4049837ee165eb18869baae",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686160095,
"kind": 1,
"tags": [
[
"e",
"1d7864ebccfc2a7a7a8cbaf22bb5e212082e3d940e52b7846e104e9da11de1ef",
"",
"root"
],
[
"e",
"60a53c9e7b096e8fa20e51be2f9d78ee1801861b5a57a128d05672103301d7c0",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2016-01-29\n📝 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.\n\n\u003e On Jan 28, 2016, at 11:21 PM, Btc Drak \u003cbtcdrak at gmail.com\u003e wrote:\n\u003e \n\u003e 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.\n\u003e \n\u003e 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).\n\u003e \n\u003e \n\u003e On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e Folks,\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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 \u003chttps://github.com/bitcoin/bips/pull/311\u003e\n\u003e \n\u003e 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.\n\u003e \n\u003e \n\u003e - Eric\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/a8c4af1d/attachment-0001.sig\u003e",
"sig": "234e9a1b2e635d65a9a1756b5f414b0a11ad94b376f53dff0a5db1759baf6514635b0a9f9685ca257def8784c6ca796322cb5fac4a115f4cdbd55263810f60ae"
}