BIP 100: What votes are possible?

3

1

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?

C-Otto

Posted 2015-06-12T22:06:17.843

Reputation: 151

Answers

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.

C-Otto

Posted 2015-06-12T22:06:17.843

Reputation: 151

2Do 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 – 2015-06-12T23:37:40.777

3I 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 – 2015-06-12T23:58:20.320

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: https://gist.github.com/gubatron/143e431ee01158f27db4

– Gubatron – 2015-08-12T23:32:28.487

1the 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 – 2015-08-13T07:33:08.450

183 days is a good number for software changes. no need to move it faster. – Erik Aronesty – 2015-08-18T14:35:21.553

Asked: 2015-06-12T22:06:17.843

Viewed: 920 times

Active: 2015-12-21T00:00:54.550