(*) I believe my currently favored formulation of general dynamic control
idea is that each miner expresses in their coinbase a preferred size
between some minimum (e.g. 500k) and the miner's effective-maximum;
the actual block size can be up to the effective maximum even if the
preference is lower (you're not forced to make a lower block because you
stated you wished the limit were lower).  There is a computed maximum
which is the 33-rd percentile of the last 2016 coinbase preferences
minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
larger. The effective maximum is X bytes more, where X on the range
[0, computed_maximum] e.g. the miner can double the size of their
block at most. If X > 0, then the miners must also reach a target
F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---
so the maximum penalty is 2, with a quadratic shape;  for a given mempool
there will be some value that maximizes expected income.  (obviously all
implemented with precise fixed point arithmetic).   The percentile is
intended to give the preferences of the 33% least preferring miners a
veto on increases (unless a majority chooses to soft-fork them out). The
minus-comp_max/52 provides an incentive to slowly shrink the maximum
if its too large-- x/52 would halve the size in one year if miners
were doing the lowest difficulty mining. The parameters 500k/33rd,
-computed_max/52 bytes, and f(x)  I have less strong opinions about;
and would love to hear reasoned arguments for particular parameters.