<oembed><type>rich</type><version>1.0</version><author_name>npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed</author_name><author_url>https://nostr.ae/npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2016-11-15&#xA;📝 Original message:I think this is already covered in the BIP text:-&#xA;&#xA;&#34;As of November 2016, the most recent of these changes (BIP 65,&#xA;enforced since December 2015) has nearly 50,000 blocks built on top of&#xA;it. The occurrence of such a reorg that would cause the activating&#xA;block to be disconnected would raise fundamental concerns about the&#xA;security assumptions of Bitcoin, a far bigger issue than any&#xA;non-backwards compatible change.&#xA;&#xA;So while this proposal could theoretically result in a consensus&#xA;split, it is extremely unlikely, and in particular any such&#xA;circumstances would be sufficiently damaging to the Bitcoin network to&#xA;dwarf any concerns about the effects of this proposed change.&#34;&#xA;&#xA;&#xA;On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev&#xA;&lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; NACK&#xA;&gt;&#xA;&gt; Horrible precedent (hardcoding rule changes based on the assumption that&#xA;&gt; large forks indicate a catastrophic failure), extremely poor process&#xA;&gt; (already shipped, now the discussion), and not even a material performance&#xA;&gt; optimization (the checks are avoidable once activated until a sufficiently&#xA;&gt; deep reorg deactivates them).&#xA;&gt;&#xA;&gt; e&#xA;&gt;&#xA;&gt; On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev&#xA;&gt; &lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt;&#xA;&gt; Hi,&#xA;&gt;&#xA;&gt; Recently Bitcoin Core merged a simplification to the consensus rules&#xA;&gt; surrounding deployment of BIPs 34, 66, and 65&#xA;&gt; (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a&#xA;&gt; minor one, I thought it was worth documenting the rationale in a BIP for&#xA;&gt; posterity.&#xA;&gt;&#xA;&gt; Here&#39;s the abstract:&#xA;&gt;&#xA;&gt; Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner&#xA;&gt; signaling in block version numbers. Now that the chain has long since passed&#xA;&gt; the blocks at which those consensus rules have triggered, we can (as a&#xA;&gt; simplification and optimization) replace the trigger mechanism by caching&#xA;&gt; the block heights at which those consensus rules became enforced.&#xA;&gt;&#xA;&gt; The full draft can be found here:&#xA;&gt;&#xA;&gt; https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;</html></oembed>