đź“… Original date posted:2016-01-28
đź“ť Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/2e877491/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/2e877491/attachment-0001.sig>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:48:15
in reply to nevent1q…6swn
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:48:15Event JSON
{
"id": "440ff3e169cb20c51d11083e7420f6e116d7300c65b41ecb69d9bc43d429834d",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686160095,
"kind": 1,
"tags": [
[
"e",
"1d7864ebccfc2a7a7a8cbaf22bb5e212082e3d940e52b7846e104e9da11de1ef",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2016-01-28\n📝 Original message:Folks,\n\nI 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\nFor 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\nThis 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\nWe 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\nA 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\nI 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\n\n- Eric\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/2e877491/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/2e877491/attachment-0001.sig\u003e",
"sig": "83017882f1ee2239ce8dbe75f1157cb46fa2285e8ccd824f03352bbeebc75402ca0a53662793fdbc00782f333a7b71d7446dbb8096bfebbe1849f5372bade93c"
}