Here is my thinking. The BIP process is about changes to a living project which is the bitcoin prptocol. This specific BIP got accepted and we know in the blockchain that this event (the acceptance) is recorded. Before a certain block the rules were one way, after they were changed.
I have no problem with changing the *code* to be less complex because it already knows the past. A checkpoint is the same, it is the registeration of a past event. This makes software less complex and still capable of checking the entire blockchain from genesis. I don’t see any harm in this change. I see prudent software engineering practices. On Monday, 14 November 2016 10:47:35 CET Eric Voskuil via bitcoin-dev 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). -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev