You are correct, that is a softfork. I'm surprised nobody complained
about that example before...
What I'm trying to say there is that even if the majority of miners
don't like the new rules, users can do it against pow majority. But
yeah, since it is a softfork I guess the example doesn't belong into
the Schism hardfork category. Maybe an example of a schism softfork?
There's more things in BIP99 that I wanted to improve, so I'll think
about on how to best fix this.
Thanks for pointing it out!
On Mon, Oct 17, 2016 at 2:24 PM, Henning Kopp via bitcoin-discuss
> Hi all,
> in BIP 99, there is the example of an anti-Block-creator hardfork
> which is a hardfork setting a blocklimit where the blocksize was
> unlimited previously.
> (No, I do not want to discuss about blocksize.)
> I do not quite understand why this is a hardfork. I think this is a
> From BIP99 [https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki]:
>> Anti-Block-creator hardfork
>> There's less extreme cases where changing the pow function would not
>> be necessary. For example, let's imagine a bright future where
>> commoditized ASICs are running in millions home-heaters all over the
>> world, but the block size has been completely removed and the network
>> has devolved to a very centralized system where only 2 big pools have
>> the resources to fully validate full blocks and create block templates
>> with competitive levels of transaction fees. In that case, changing
>> the pow function would be a terrible waste and a risk that could be
>> avoided. A hardfork restoring a block size limit could help fixing
>> this situation. Please don't take it as an argument for or against
>> raising the block size limit: it's just an example. But in this case,
>> again, those 2 big pools would probably be against the fork and,
>> again, their voting is irrelevant.
> A hardfork is "A consensus fork that makes previously invalid blocks
> valid. Hardforks require all users to upgrade."(BIP99). Which
> previously invalid blocks become valid in the example above? Rather it
> is the other way around, that previously valid blocks (with great
> size) become invalid, and thus a softfork.
> All the best
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> bitcoin-discuss mailing list
bitcoin-discuss mailing list