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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
