📅 Original date posted:2016-11-14
📝 Original message:NACK
Horrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a sufficiently deep reorg deactivates them).
e
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a minor one, I thought it was worth documenting the rationale in a BIP for posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161114/03f1190e/attachment.html>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:54:16
in reply to nevent1q…4f9p
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 17:54:16Event JSON
{
"id": "adb7220e85ee2d04198dceb39b2936eceadaeee01262ef0b7b75165229d47636",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160456,
"kind": 1,
"tags": [
[
"e",
"50cde70d11f9c69cc787e52010ba0256918f920ad1f9811ad6566a1543ec1282",
"",
"root"
],
[
"e",
"23d80192d729f00e7d6488964424b3badd58aaf6c3800094f5fd38e7bb0e67b1",
"",
"reply"
],
[
"p",
"841503960589cc9bc44213e4addc2aa2fe3fe0727b79f90df3cbd6762875c31e"
]
],
"content": "📅 Original date posted:2016-11-14\n📝 Original message:NACK\n\nHorrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a sufficiently deep reorg deactivates them).\n\ne\n\n\u003e On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Hi,\n\u003e \n\u003e Recently Bitcoin Core merged a simplification to the consensus rules surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a minor one, I thought it was worth documenting the rationale in a BIP for posterity.\n\u003e \n\u003e Here's the abstract:\n\u003e \n\u003e Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.\n\u003e \n\u003e The full draft can be found here: \n\u003e \n\u003e https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161114/03f1190e/attachment.html\u003e",
"sig": "c6f11d90bd6d4d97b018fb88c3c9a69b1d4d5378c90b8b1daa42b795b06b43ff55c8b69191b65b75d04dc710e8a34c30af48ccf7635d4512bb6ab58cc0e86720"
}