The change replaced the trigger mechanism by caching the block heights at which those consensus rules became enforced. Prior soft forks were activated via miner signaling in block version numbers. Since the chain had long since passed the blocks at which those consensus rules have triggered, this was done as a simplification and optimization. The proposal also adds that the heights are required in the absence of BIP34-style activation so that the soft fork validation rules can be properly enforced at those points (whether or not a deep reorg happens). This resulted in a discussion among developers, with Eric Voskuil initially opposing the change. He argued that it set a horrible precedent, had an extremely poor process, and was not even a material performance optimization. However, others pointed out that there was no confusion among the implementers that it was a hard fork. Some also stated that the change merely cemented into place a few attributes of the blockchain's history that were not in dispute and that the change was unlikely to cause a consensus split. During the discussion, BIP30, which resolved a catastrophic protocol flaw, was brought up as an example of a previous change that had been given similar treatment after a reasonable amount of time had passed. BIP50, which documented the release of an "unexpected" hard fork to a large number of users, was also mentioned. It was noted that anyone can create an altcoin, but the question was specifically why one would want to do so in this case.