<div dir="ltr"><div>I woudl like to propose a BIP that works something like this:<br><br>1. Allow users to signal readiness by publishing an EB. This EB is an absolute upper bound, and cannot be overridden by miners. Current EB is 1MB, the status-quo.   Maybe EB can be configured in a config file, not a UI, since it&#39;s an &quot;advanced&quot; feature.<br><br>2. Miners can also signal readiness by publishing their own EB in a block.<br><br>3. If 95% of blocks within a one month signalling period contain an EB greater than the previous consensus EB, a fork date is triggered at 6 months using the smallest 5th percentile EB published. (Other times can be selected, but these are fairly conservative, looking for feedback here).    Miner signalling is ignored during the waiting period.<br><br>4. Block heights used for timing<br><br>5. After 6 months, any users which already have the new EB or greater begin actually using it to validate transactions. Users use the EB or the latest 95% consensus triggered value - whichever is less.   This means that the portion of users that originally signaled for the increase do not have to upgrade their software to participate in the hard fork.<br><br></div>6. Core can (optionally) ship a version with a default EB in-line with their own perceived consensus.   <br><div><br></div><div>7. Some sort of versioning system is used to ensure that the two networks (old and new) are incompatible... blocks hashed in one cannot be used in the other.<br><br></div><div>Any users which don&#39;t already have the new EB or greater should update their EB within the 6 month period - or they will be excluded from the majority fork.<br><br>It would be in the best interests of major exchanges and users would to publicly announce their EB&#39;s.<br><br>Users are free to safely set very high EB levels, based on their current hardware and network speeds. These EB levels don&#39;t cause those users to accept invalid blocks ever. They are safe because block size transitions behave like normal hard forks with high miner consensus (95%).<br><br>No code changes will be needed to fork the network as many times as both users and miners feel the need to do so.  (Bitcoin core is off the hook for &quot;scaling&quot; issues...forever!)<br><br>If a smaller block size is needed, a reduced size can also be published and agreed upon by *both* users and miners using a the same mechanism, but the largest 5th percentile is used.   In other words... the requires broad consensus to deviate from status quo and fork.<br><br>Any new node can simply follow these rules to validate all the blocks in a chain... even if the sizes changes a lot (at most twice per year).<br><br><br></div></div>