3

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?

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
5
  • 2
    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
    Jun 12, 2015 at 23:37
  • 3
    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
    Jun 12, 2015 at 23:58
  • 1
    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: gist.github.com/gubatron/143e431ee01158f27db4
    – Gubatron
    Aug 12, 2015 at 23:32
  • 1
    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
    Aug 13, 2015 at 7:33
  • 1
    83 days is a good number for software changes. no need to move it faster.
    – Erik Aronesty
    Aug 18, 2015 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.