Making something smaller would lead to wasted or unused space, but isn’t necessarily incompatible. That’s why I think decreasing block size would be a soft fork instead of hard. This differs from increasing in that you can’t fit something larger in something smaller, hence hard fork
332 sats \ 1 reply \ @ek 8 Aug
I think OP is talking about miners running the old version mining blocks that are too big for the new nodes and thus causing a similar chain split. Instead of old nodes rejecting new blocks, new nodes would reject "old" blocks (new blocks that are mined with old consensus rules).
So I think this is the essential question:
Do such soft-forks always require miner cooperation first?
Yes, according to my knowledge, that is the case.
Initial segwit adoption requires the participation of two groups:
  • Miners representing 95% or more of the total Bitcoin network hash rate must signal support for segwit in order to lock-in segwit’s activation.
  • Full nodes run by a reasonable number of users and business to validate the payments they receive need to be upgraded to Bitcoin Core 0.13.1 or above, or another segwit-compatible implementation in order to incentivize miners to follow segwit’s rules after segwit activates. (This is Bitcoin’s normal incentivization mechanism where miners only receive income for generating a block if they follow all of the consensus rules, which will include the new segwit consensus rules once segwit activates.)
reply
deleted by author
reply