<p>Gregory Maxwell in IRC:</p>

<blockquote>
  <p>the scheme would have the pariticiants specify the size they want, and
  at the end the period the smallest 25% would be tossed and the
  smallest remaining would be used.</p>
</blockquote>

<p>So in each block there would be a field, initially set to 2 MByte. A miner is free to set any value (up to 2x the current limit).
Assuming we have the following values set in the last 12,000 blocks:</p>

<ul>
<li>20% 2 MByte</li>
<li>20% 3 MByte</li>
<li>60% 4 MByte</li>
</ul>

<p>Then, because only 60% want 4 MByte but 80% agree to have 3 MByte, the limit is increased to 3 MByte.</p>

<p>There would be a new vote every 12,000 blocks, and a decrease also would be possible if that is what the miners want.</p>

CC BY-SA 3.0
2015-06-12T23:37:40.777Z
Do they toss 25% of all votes including nodes that don't express a preference, or 25% of the nodes that vote? E.g. If it was 20% abstention, 15% 4MB, and 65% 3MB, would they pick 4 or 3 megabytes?
Nick ODell
CC BY-SA 3.0
2015-06-12T23:58:20.320Z
I don't think it is possible to not express a preference. In your example the 20% would vote for the status quo (2 MByte), 15% for 4 MByte and 65% for 3 MByte. That would result in a change to 3 MByte. I don't see how 4 MByte would be an option with those percentages.
C-Otto
CC BY-SA 3.0
2015-08-12T23:32:28.487Z
12,000 blocks is about 83 days... really? 
Why not make the voting periods happen every hour if necessary?
that's not very good to adapt to a monthly surge in real demand.

been trying to bounce this idea instead, no voting, simply adjust to the needs of the network to try to keep the network putting most transactions on the blockchain below 45mins:
https://gist.github.com/gubatron/143e431ee01158f27db4
Gubatron
CC BY-SA 3.0
2015-08-13T07:33:08.450Z
the idea is that with 83 days everyone can see changes coming well in advance and act accordingly. so even if miners rocket the limit up to 20mb asap to force more centralization we'll be able to see that coming and move to an altcoin
Ruben de Vries
CC BY-SA 3.0
2015-08-18T14:35:21.553Z
83 days is a good number for software changes.     no need to move it faster.
Erik Aronesty
CC BY-SA 3.0
2015-06-12T22:57:42.267Z
2015-06-12T22:57:42.267Z
C-Otto
<p>I understand that, with BIP 100 as suggested by Jeff Garzik, in the first step the maximum block size can be increased from (then, after the hard fork) 2 MByte to at most double of that, so 4 MByte - without a hard fork. Depending on the miner's votes (counted for 12.000 blocks, 75% majority necessary) the block size may be increased further.</p>

<p>How can I, as a user start the voting process? What if I'm a miner? How do I determine the new maximum block size? Can two votes for 3 MByte and 4 MByte run in parallel?</p>

<block-size-increase><bip>
BIP 100: What votes are possible?
C-Otto
# BIP 100: What votes are possible?

(Asked by: username_0 on 2015-06-12)

I understand that, with BIP 100 as suggested by Jeff Garzik, in the first step the maximum block size can be increased from (then, after the hard fork) 2 MByte to at most double of that, so 4 MByte - without a hard fork. Depending on the miner's votes (counted for 12.000 blocks, 75% majority necessary) the block size may be increased further.

How can I, as a user start the voting process? What if I'm a miner? How do I determine the new maximum block size? Can two votes for 3 MByte and 4 MByte run in parallel?

**Tags:** block-size-increase, bip


---

## 1 answers

### Answer by username_0 on 2015-06-12. Score: 2 | Accepted answer

Gregory Maxwell in IRC:

> the scheme would have the pariticiants specify the size they want, and
> at the end the period the smallest 25% would be tossed and the
> smallest remaining would be used.

So in each block there would be a field, initially set to 2 MByte. A miner is free to set any value (up to 2x the current limit).
Assuming we have the following values set in the last 12,000 blocks:

* 20% 2 MByte
* 20% 3 MByte
* 60% 4 MByte

Then, because only 60% want 4 MByte but 80% agree to have 3 MByte, the limit is increased to 3 MByte.

There would be a new vote every 12,000 blocks, and a decrease also would be possible if that is what the miners want.

> **Comments:**
> **username_1**: Do they toss 25% of all votes including nodes that don't express a preference, or 25% of the nodes that vote? E.g. If it was 20% abstention, 15% 4MB, and 65% 3MB, would they pick 4 or 3 megabytes?  
> **username_0**: I don't think it is possible to not express a preference. In your example the 20% would vote for the status quo (2 MByte), 15% for 4 MByte and 65% for 3 MByte. That would result in a change to 3 MByte. I don't see how 4 MByte would be an option with those percentages.  
> **username_2**: 12,000 blocks is about 83 days... really?  Why not make the voting periods happen every hour if necessary? that's not very good to adapt to a monthly surge in real demand.  been trying to bounce this idea instead, no voting, simply adjust to the needs of the network to try to keep the network putting most transactions on the blockchain below 45mins: https://gist.github.com/username_2/143e431ee01158f27db4  
> **username_3**: the idea is that with 83 days everyone can see changes coming well in advance and act accordingly. so even if miners rocket the limit up to 20mb asap to force more centralization we'll be able to see that coming and move to an altcoin  
> **username_4**: 83 days is a good number for software changes.     no need to move it faster.  

---

