BIP-100.5: Progressive Block Size Limit Voting with Default Growth Rate

[Michael_S]

I wrote another (much simpler!) proposal for combining the best of BIP-100 and BIP-101, so I called it "BIP-100.5" for now.

I focussed on...

* Decentralization
* User adoption over time
* Technological progress over time
* The uncertainty of the two above
* Interests of the eco-system
* Interests of the miners
* Reasonability and pragmatism
* Likelihood of adoption
* Simplicity of implementation

Although I used BIP-100 as the template, there are too many changes for making it a pull request to BIP-100 I think.


Abstract
This BIP proposes to replace the fixed 1 MB block size limit with an adaptive limit that can float between 1 MB and 61 GB (temporarily 1..32 MB) based on a default growth rate and miner voting. This combines the merits of BIP-100 and BIP-101 within a new generalized mechanism. Both BIP-100 and BIP-101 can be considered special cases of this BIP, depending on the choice of hard-coded parameters.

Full description here: https://github.com/1MichaS1/BIP100dotFive

Fierce proponents of BIP-100 and BIP-101 respectively will probably not like any other proposal than "their's" - for the vast majority I am hoping it can be a reasonable compromise that can achieve wide consensus.

Illustration: Possible block size limit evolutions for certain miner majorities (for comparison the growth rates of 17.7% and 41.4% are included) - log scale:

Note: With BIP-100, the "red default" line would be at 0.0% growth (horizontal), the 80% and 90% lines would be about where the 90% lines are in above figure, and all other lines would be 0.0% (horizontal) like the red default line. With BIP-101, all lines would be collapsed to where the +41.4% line is in above figure.


The reason why in this BIP the default growth rate is not 0.0% but some moderate positive value is that the default should, at least in tendency, follow the "bathtub":

Centralization
of Bitcoin system
  .
 /|\
  |*                                                                     *
  |*                                                                     *
  | *  (a) More users                                                   * (b) Technol. progr.
  |  * ----> time                                                      *  ----> time
  |   *                                                               *
  |    *                        ----> time                           *
  |      *      Area of best Bitcoin system decentralization       *
  |        *    |<----------------------------------------->|    *  
  |             *   *   *   *   *   *   *   *   *   *   *   *
  '--------------------------------------------------------------------------->
                                                               block size limit

Left edge = centralization due to too low capacity (tx per second, congestion, users pushed off-chain).
Right edge = centralization due to too high bandwidth + storage requirements.
Both edges move to the right as time passes, this BIP's default growth tries to stay in the flat area of the bathtub.
Voting enables deviation from the default growth.

Looking forward to your opinions!

[jonny1000]

BIP100.5 is not consistent with the existing power structure so the voting could be undermined. This is with respect to an increase in the limit with just 35% of votes. 50% of the miners can impose a lower limit and prevent themselves being ruled by a minority, if they collaborate and orphan all blocks above a certain size. This fact needs to be reflected in the voting mechanism, otherwise the voting system ignores reality and could be overuled in some circumstances.

For example if 64% of miners do not want an increase, but the BIP100.5 voting process results in an increase, the vote itself can be used as a mechanism to justify a 64% cartel who can impose a lower limit anyway and undermine the voting process.

Please note this is not true for a vote to decrease the limit, as non mining nodes will enforce this rule, so 50% of miners cant overule it.

If this discrepancy is corrected such that at least 50% of miners are required to support an increase before it occurs, I consider this proposal potentially acceptable.