Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.

You need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently.  

Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.

On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail.com> wrote:

On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
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.

True.

BIP 100 and 101 could be combined.  Would that increase consensus?

- Miner vote threshold reached
- Wait notice period or until earliest start time
- Block size default target set to 1 MB
- Soft limit set to 1MB
- Hard limit set to 8MB + double every 2 years
- Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)

Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.

Miners could leave the 1MB limit in place initially.  The vote is to get the option to increase the block size.

Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block.

If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client.  If they give notice and enough users update, then miners would have to accept it.

The block size becomes min(miner's vote, core devs).  Even if 4 years notice is given, blocks would only be 4X optimal.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev