jgarzik / bip100 Goto Github PK

I suggest changing from votes from a string "/BVnnnnnnnn/" to a 4 byte unsigned integer where the integer is the blocksize in bytes. There's no need to take up so much space in the coinbase field.

@jgarzik I don't remember the result of the discussion back in January, but I think the conclusion was that you create a pull request against bitcoin/bips with this branch even though number 100 was never assigned.

From the current spec:

b. Votes are limited to +/- 20% of the current hardLimit.
c. Sort the votes from the previous 12,000 blocks from lowest to highest.
d. The raise value is defined as a vote for 2400th highest block (20th percentile).
e. The lower value is defined as a vote for 9600th highest block (80th percentile).
f. If the raise value is higher than current hardLimit, the new limit becomes the raise value.
g. If the lower value is lower than current hardLimit, the new limit becomes the lower value.
h. Otherwise, hardLimit is unchanged.

Also,

1. 75% rule: If 9,000 of the last 12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
2. 95% rule ("Point of no return"): If 11,400 of the last 12,000 blocks are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last 1000)

My clarification request is this:

What is the first block considered as part of the voting process?

• Since there is a 12,000+ block deployment period, can miners already be voting during that time, and the block size can change at the first 2016-block difficulty adjustment?
• Or: are votes only counted after deployment at Block XXXXXX, and thus is the first 2016-block difficulty adjustment after block XXXXXX+11999 the first time the block size can increase?

Can I suggest you add a "deployment" section in the BIP and move points 5 & 6 there. This is more in line with how BIPs have been written in the past.

(Ideally it would be better also to have the deployment section left at TBD).

Quote 1:

ii. A new hardLimit is calculated at each difficult adjustment period (2016 blocks), and applies to the next 2016 blocks.

Quote 2:

b. Votes are limited to +/- 20% of the current hardLimit.
c. Sort the votes from the previous 12,000 blocks from lowest to highest.
d. The raise value is defined as a vote for 2400th highest block (20th percentile).
e. The lower value is defined as a vote for 9600th highest block (80th percentile).
f. If the raise value is higher than current hardLimit, the new limit becomes the raise value.
g. If the lower value is lower than current hardLimit, the new limit becomes the lower value.
h. Otherwise, hardLimit is unchanged.

After a hardLimit adjustment at Block XXXXXX, can the hardLimit adjust again at Block XXXXXX+2016 (allowing reuse of voted from Blocks XXXXXX-9085 through XXXXXX-1)?

Or, are those votes note reusable, and is the next possible hardLimit adjustment at Block Block XXXXXX+12096?

-- Apologies if my "XXX+" and "XXX-" numbers are off by +/- 1, but I think I marked them correctly.