[BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug

[Michael_S]

Hi,

after having read BIP100, 101, 102 and 103(?), after having seen many discussions, after having heard many arguments, after weighing many pros and cons, after having read study reports about the effects of congestion in the transaction queues, after thinking for myself what other solutions might exist, I made a write-up about a solution that combines and considers many ideas and concerns. I have made several iterations of improvements before releasing the first version to the public today.

Unfortunately(?), the document has become larger than planned, it has 37 pages, but for a quick read you already get an impression when reading only page 1 (abstract) and pages 7+8 (overview).

Fortunately, it is well structured and full of information. It does not only give some basic ideas but specifies the solution down to a very detailed level close to implementation. It also has a separate chapter giving the rationale for many design decisions, and it provides simulation results (incl. simulation code) to see how the method behaves in certain corner cases.

Now I hope you have the time to read and understand the paper, and I am looking forward to hearing your thoughts. I think the interested reader will find an inspiring mixture of known and new ideas, combined in a way and detailed down to a level as it has not been seen before.

[Last update 5 Sept 2015, ~15:30 CEST]: OVERVIEW DOCUMENT in BIP Format / Github:

• BIP mediawiki format at Github

[Last update 5 Sept 2015, ~2:00 CEST]: FULL SPECIFICATION (39 pages):

• BIP10X_Block_Size_Limit_Adaptation_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_v02.pdf Dropbox Download

Further sources (will not be updated as frequently as Github format above, with same content as in Github repository):

[Last update 5 Sept 2015, ~2:00 CEST]: Overview Document as PDF file (5 pages):

• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf Dropbox Download

Looking forward to hearing from you!  
Michael

PS: I have not yet tried to apply for a BIP number (but will probably do so later), that's why I put a placeholder and am calling it "BIP10X" for now.

[1714121947]

1714121947

[1714121947]

1714121947

[1714121947]

1714121947

[CounterEntropy]

Could you please write it up in prescribed BIP format, like BIP 1xx did ?

[Michael_S]

I wrote an overview document in quite that format - now only 5 pages.

Indeed, this is a bit easier and much faster to read than the more comprehensive 37 pages.

Please find it here as PDF (v0.2):

• BIP Format at Github
• SCRIBD: https://de.scribd.com/doc/278450599/A-Hybrid-Mechanism-for-Adaptively-Adjusting-Bitcoin-s-Block-Size-Limit-BIP10X-Short-Overview
• DROPBOX Download: https://www.dropbox.com/s/mw3e30kju9t86uj/BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf?dl=0

Please judge it by the content and not by the fact that I put it on dropbox.  Thanks!

[Michael_S]

I now wrote it in BIP format at Github:

• BIP Format at Github

[erik777]

Interesting proposal.  The concerns I'd have include:

- If a vote must be used to initiate the hard fork, it should be 95%.  Note that this concept only became necessary because of the XT code fork.  Otherwise, we could of just set a date in the future and asked miners to upgrade by then. 

- Not sure why we want miners voting every week. 

   1> Miners are unlikely to want to interact.  How would this work with ASICs?  Miners probably don't want to have to update anything on a weekly basis. 

  2> Why would miner voting be needed for anything other than the hard fork?  Couldn't we just have it always calculate the block size limit periodically based on history?  I see you have a notion of this.  Buy, why as a fall-back instead of the primary method?
 

 

[Michael_S]

Hello erik,

thank you for reading and commenting.

Interesting proposal.  The concerns I'd have include:

- If a vote must be used to initiate the hard fork, it should be 95%.  Note that this concept only became necessary because of the XT code fork.  Otherwise, we could of just set a date in the future and asked miners to upgrade by then.  

In the presence of the many BIPs, I think a supermajority criterion is needed. I am not sure why 95% would be better than 75%. I think 75% is enough, and I think 95% might not be reachable. Of course, if a consensus could be reached and "bitcoin-core" or another project convinces everybody to use the SW, then the new BIP10X protocol could be simply activated at a given block height.

My assumption though was that we are dealing here in a somewhat competitive environment between different proposals.

- Not sure why we want miners voting every week.  

Maybe a misunderstanding. Miners don't vote "every week", they vote continuously in "every block". The 1 week relates to the intervals in which miner votes are EVALUATED and possibly adjustments on the block size limit take place. I re-phrased this in my updated version at Github, to avoid this misunderstanding in the future.

  1> Miners are unlikely to want to interact.  How would this work with ASICs?  Miners probably don't want to have to update anything on a weekly basis.  

They don't need to. This "BIP10X" proposal suggests that miner operators do not need to interact but just configure what is their voting preference in "bitcoin.conf", and then the miner will automatically cast the correct vote according to miner operator's preferences. Operator can adjust his preferences any time (no need to respect the 1-week-intervals in any way). Also note that instead of the voting strategy "vote for fixed value", miner operator can also configure via bitcoin.conf that the voting strategy should for example be "vote for average actual block size of last week times a certain self-selected factor", or miner can vote for "same block size limit as current block size limit".

 2> Why would miner voting be needed for anything other than the hard fork?  Couldn't we just have it always calculate the block size limit periodically based on history?  I see you have a notion of this.  Buy, why as a fall-back instead of the primary method?

First, I use the actual block size criterion as a "constraint", not a "fall back" method. (But maybe you understood it right and just termed it differently)

You suggest auto-adaptation of BlockSizeLimit e.g. solely based on the actual fillings of the blocks? In principle possible, but I want to introduce miner voting "institutionalized" inside the protocol, to avoid tiring "block size limit"-motivated hard fork discussions for the future, as we have it now. Because if miners can vote within the protocol, they do not need to vote for a completely new hardfork SW but can just use the voting mechanisms already present within the protocol. I also wrote it like this in the "Motivation" section of the BIP10X proposal.

Also, we see from miners' reactions today that they like a solution where they can actively vote, hence their BIP100 support is so great. And we cannot ignore this fact. But I want to propose a solution that removes the drawbacks of BIP100 (which maybe not all miner operators have completely figured out and are aware of), i.e. an improved version of BIP100 if you want, that the miners can hopefully also well agree with, hopefully even better than with BIP100 itself. One could consider BIP10X an evolution of BIP100.

Another reason against complete "auto-adaptation" without voting is that there could be natural (e.g. seasonal) periods of lesser traffic that should not necessarily promptly lead to BlockSizeLimit adaptations (decrease) too soon. I really think that voting (or the human = miner's influence) should play an important role, and the "actual block size" constraint  should only step in if the divergence between actual block size and BlockSizeLimit vote becomes too much.

[achow101]

Interesting proposal.  The concerns I'd have include:

- If a vote must be used to initiate the hard fork, it should be 95%.  Note that this concept only became necessary because of the XT code fork.  Otherwise, we could of just set a date in the future and asked miners to upgrade by then.  

In the presence of the many BIPs, I think a supermajority criterion is needed. I am not sure why 95% would be better than 75%. I think 75% is enough, and I think 95% might not be reachable. Of course, if a consensus could be reached and "bitcoin-core" or another project convinces everybody to use the SW, then the new BIP10X protocol could be simply activated at a given block height.

My assumption though was that we are dealing here in a somewhat competitive environment between different proposals.

It should be 95% for supermajority. BIP 101 is idiotic for using 75% and calling that the supermajority. All previous BIPs that had soft forks used 95% of the last N (usually 1000) blocks. Since this would be a hard fork, it should definitely have at least the same supermajority standards.

[Michael_S]

I'd like to postpone the discussion about what would be the optimum percentage for activation of a new BIP that deals with BlockSizeLimit evolution, since this parameter is really not at the core of this "BIP10X". Certainly there is no god-given optimum value, and different people will have different viewpoints here. But this is a secondary discussion, which is distracting from the main topic.

I would prefer a discussion about this BIP10X proposal as such (i.e. its solution once it is operational).

Because, it intends to fix the most criticized weaknesses of BIP100 and BIP101 (criticized not only by community members, but also from my own view), therefore I think it is really worth considering and may have the potential to gain the greatest consensus.

[teukon]

• If actual blocks are filled by >90% on average, block size limit will increase long-term by +41% p.a., even if 100% of miners vote in opposite direction [Rat-4]. Of course, a vote majority of >80% in the same direction can further increase growth rate to avg. +100% p.a.

I think this is going to turn off some of the BIP100 supporters.  I believe that the key to BIP100 is to give miners a way to coordinate restrictions on supply, forcing transaction creators to compete for earlier block inclusion with higher fees.  I think the goal is to drive up fee totals and thereby increase network security.  By allowing the state of consistently well-filled blocks to override miner's votes you seem to reintroduce the tragedy of the commons that BIP100 sought to tackle.

As a BIP101 supporter, my main concern is with miner centralisation in the case that demand grows faster than supply.  100% p.a. growth will very likely outpace gains in bandwidth.  Perhaps you could briefly explain how your proposal counters this problem.