Quote from: Peter R on September 04, 2015, 06:19:27 PM

Quote from: jonald_fyookball on September 04, 2015, 05:58:26 PM

The hardcoding of a blocksize is part of consensus just as they are running the same codebase overall. I question the wisdom of making that part of the code at all. However, it seems that having no limit could be problematic, and as Panther pointed out, miners do want some predictability, which is why I'm liking Bip100 more. Do you know if Jeff Garzik ever considered making it a 51% vote?

Sickpig (forum member here) suggested that the block size limit was a transport layer constraint that crept into the consensus layer. I agree. I don't think we really need a protocol enforced limit because:

1. There is a significant economic cost to producing large spam blocks as an attack.

2. There is a physical limitation to how large a block can be (due to bandwidth and other constraints).

3. The miners can enforce an effective limit anyways.

BIP100 seems redundant (and dangerous if it's not based on majority votes). Let's get rid of the limit and let the miners sort it out.

These costs, as it has been explained to you repeatedly, are trivial given incremental centralization. In other words miners are incentivized to centralize so as to limit their orphan risks and create larger blocks.

"The miners" cannot enforce a limit. Individual miners can "vote" for a certain limit but never enforce it for the whole network. Under no block size cap, smaller miners have no control and can easily be choked out of the network by larger ones putting more hashpower in support of "their" limit.