rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2015-05-06 📝 Original message:On 05/06/15 23:33, Tier Nolan wrote: > On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me > <mailto:bitcoin-list at bluematt.me>> wrote: > > The point of the hard block size limit is exactly because giving miners > free rule to do anything they like with their blocks would allow them to > do any number of crazy attacks. The incentives for miners to pick block > sizes are no where near compatible with what allows the network to > continue to run in a decentralized manner. > > > Miners can always reduce the block size (if they coordinate). > Increasing the maximum block size doesn't necessarily cause an > increase. A majority of miners can soft-fork to set the limit lower > than the hard limit. Sure, of course. > Setting the hard-fork limit higher means that a soft fork can be used to > adjust the limit in the future. > > The reference client would accept blocks above the soft limit for wallet > purposes, but not build on them. Blocks above the hard limit would be > rejected completely. Yes, but this does NOT make an actual policy. Note that the vast majority of miners already apply their own patches to Bitcoin Core, so applying one more is not all that hard. When blocks start to become limited (ie there is any fee left on the table by transactions not included in a block) there becomes incentive for miners to change that behavior pretty quick. Not just that, the vast majority of the hashpower is behind very large miners, who have little to no decentralization pressure. This results in very incompatible incentives, mainly that the incentive would be for the large miners to interconnect in a private network and generate only maximum-size blocks, creating a strong centralization pressure in the network.