Actually this does nothing to provide justification for this consensus rule change. It is just an attempt to deflect criticism from the fact that it is such a change.
e > On Nov 15, 2016, at 9:45 AM, Btc Drak <[email protected]> wrote: > > I think this is already covered in the BIP text:- > > "As of November 2016, the most recent of these changes (BIP 65, > enforced since December 2015) has nearly 50,000 blocks built on top of > it. The occurrence of such a reorg that would cause the activating > block to be disconnected would raise fundamental concerns about the > security assumptions of Bitcoin, a far bigger issue than any > non-backwards compatible change. > > So while this proposal could theoretically result in a consensus > split, it is extremely unlikely, and in particular any such > circumstances would be sufficiently damaging to the Bitcoin network to > dwarf any concerns about the effects of this proposed change." > > > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev > <[email protected]> wrote: >> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
