rich1.0npub1ss2s89s938xfh3zzz0j2mhp25tlrlcrj0duljr0ne0t8v2r4cv0q5e0am4https://nostr.ae/npub1ss2s89s938xfh3zzz0j2mhp25tlrlcrj0duljr0ne0t8v2r4cv0q5e0am4njumphttps://nostr.ae📅 Original date posted:2016-11-15 📝 Original message:Just want to clarify two points: This change has not yet appeared in any released software (but I assume it will be in the next release, 0.14.0). I agree that the performance optimization is not the point of this change; I can modify the BIP draft to de-emphasize that further (perhaps remove mention of it entirely). On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <eric at voskuil.org> 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 < > 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/20161115/7b2641ce/attachment.html>