Regarding the block size increase, at least conceptually it seems to me there should be an easy solution. If we look at what works well with bitcoin, for example the block reward halving and difficulty regimes which due to their step function nature both contribute to the stability and predictability of the bitcoin universe while still allowing for the necessary dynamic adjustments. It seems to me there should be a corresponding and equally simple solution for the maximum block size.

I've never quite understood the supposed rationale behind the proposals for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be trivial to implement. Why not come up with an equally simple, predictable dynamic function consistent with what is already proven to work in the bitcoin universe that would both preserve the scarcity of transaction capacity to encourage a fee market but also allow for more transactions when needed.

For example how about something like once every month at month-end, take the 6-month average non-zero transaction fee block size and multiply by 1.5?

With the # of transactions increasing then plateauing you arrive at a constant excess capacity of around 33%:
   
MO    ABS    MBS    EX CAP
1    750    1000    25.0%
2    775    1000    22.5%
3    800    1000    20.0%
4    825    1000    17.5%
5    850    1000    15.0%
6    875    1219    28.2%
7    900    1256    28.4%
8    925    1294    28.5%
9    950    1331    28.6%
10    975    1369    28.8%
11    1000    1406    28.9%
12    1000    1438    30.4%
13    1000    1463    31.6%
14    1000    1481    32.5%
15    1000    1494    33.1%
16    1000    1500    33.3%
17    1000    1500    33.3%
18    1000    1500    33.3%

Similarly, in a declining then plateauing # of transactions market you also arrive at a constant excess capacity of about 33%

MO    ABS    MBS    EX CAP
1    750    1000    25.0%
2    725    1000    27.5%
3    700    1000    30.0%
4    675    1000    32.5%
5    650    1000    35.0%
6    625    1031    39.4%
7    600    994    39.6%
8    575    956    39.9%
9    550    919    40.1%
10    525    881    40.4%
11    500    844    40.7%
12    500    813    38.5%
13    500    788    36.5%
14    500    769    35.0%
15    500    756    33.9%
16    500    750    33.3%
17    500    750    33.3%
18    500    750    33.3%

With some simple statistical analysis, one could easily arrive at a statistically-inferred excess capacity linked the to probability of transaction volume exceeding the new cap in any forward monthly interval. In the tables above, I have used my own intuition that people seem to be generally comfortable with excess capacity of >= 33% and become less so at < 33%.

A scheme like this would have multiple benefits:

1) Adapts predictably and automatically to both rising and declining market demand for transactions

2) Preserves the fee market with a constant target excess capacity

3) Monthly adjustment interval and six month lookback allow for sufficient time to plan for changes in system capacity

In the case where transaction volume spikes such that it exceeds the monthly limit, the fee market would then take over to ensure high priority transactions get through fastest. In the case of malicious activity, such an attack would have to be maintained for well over a month to significantly adversely affect the maximum block size. As long as there is a non-zero cost to such attacks, the likelihood of maintaining one for a period of months decreases significantly.

Thx,

JTW

On 7/31/2015 1:45 PM, Eric Lombrozo via bitcoin-dev wrote: