> > 3) Let me put it another way, I've read that both Gavin and yourself are > favorable to a dynamic limit on the block size. In your view, what is > missing from this proposal, or what variables should be adjusted, to get > the rules to a place where you and other Core developers would seriously > consider it? >
I'm not clear on what problem(s) you're trying to solve. If you want blocks to be at least 60% full, then just specify a simple rule like "maximum block size is 1.0/0.6 = 1.666 times the average block size over the last N blocks (applied at every block or every 2016 blocks or whatever, details don't really matter)". If you want an upper limit on growth, then just implement a simple rule like "Absolute maximum block size is 1 megabyte in 2016, 3.45 megabytes in 2017, and increases by a maximum of 3.45 times every year." If you want me to take your proposal seriously, you need to justify why 60% full is a good answer (and why we need a centralized decision on how full blocks "should" be), and why 3.45 times-per-year is a good answer for maximum growth (and, again, why we need a centralized decision on that). -- -- Gavin Andresen
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
