{"type":"rich","version":"1.0","author_name":"npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","author_url":"https://nostr.ae/npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-11-15\n📝 Original message:I think this is already covered in the BIP text:-\n\n\"As of November 2016, the most recent of these changes (BIP 65,\nenforced since December 2015) has nearly 50,000 blocks built on top of\nit. The occurrence of such a reorg that would cause the activating\nblock to be disconnected would raise fundamental concerns about the\nsecurity assumptions of Bitcoin, a far bigger issue than any\nnon-backwards compatible change.\n\nSo while this proposal could theoretically result in a consensus\nsplit, it is extremely unlikely, and in particular any such\ncircumstances would be sufficiently damaging to the Bitcoin network to\ndwarf any concerns about the effects of this proposed change.\"\n\n\nOn Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e NACK\n\u003e\n\u003e Horrible precedent (hardcoding rule changes based on the assumption that\n\u003e large forks indicate a catastrophic failure), extremely poor process\n\u003e (already shipped, now the discussion), and not even a material performance\n\u003e optimization (the checks are avoidable once activated until a sufficiently\n\u003e deep reorg deactivates them).\n\u003e\n\u003e e\n\u003e\n\u003e On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev\n\u003e \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\n\u003e surrounding deployment of BIPs 34, 66, and 65\n\u003e (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a\n\u003e minor one, I thought it was worth documenting the rationale in a BIP for\n\u003e 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\n\u003e signaling in block version numbers. Now that the chain has long since passed\n\u003e the blocks at which those consensus rules have triggered, we can (as a\n\u003e simplification and optimization) replace the trigger mechanism by caching\n\u003e 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 _______________________________________________\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\u003e\n\u003e\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\u003e"}