Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a growth limiter as a hard-cap and a mechanism for influencing a dynamic cap within that envelope.
The hard-cap serves the purpose of a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case. More comments to follow. Adam On 25 June 2015 at 15:50, Gareth Williams <gac...@gmail.com> wrote: > On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgar...@gmail.com> wrote: >>Miners can collude today to lower the block size limit. > > Of course they can. What, then, is the need for BIP100's hard-limit voting > mechanism? > > You only need consensus rules to enforce block size limits if you're > enforcing them _against_ miners. Which may be a perfectly valid thing to do > (if your threat model includes, for example, the possibility that large > miners deliberately create large blocks to gain an advantage over small > miners.) But BIP100 doesn't address that anyway. > > Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB > hard-limit growth curve*, and then encourage miners to enforce a soft limit > below that, agreed through a voting mechanism? The later can be implemented > at any time without consensus changes -- nobody can prevent miners from > coordinating the max block size they'll build on anyway. > > * but with a safer "supermajority" than 75% please :) > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
