Author: jl2012 at xbt.hk 2015-09-03 16:32:15
Published on: 2015-09-03T16:32:15+00:00
The discussion on Bitcoin-dev mailing list includes several points related to the block size limit. One suggestion is that there is no need for byte level resolution, but rather kilobyte (kB) resolution would be a better choice. Another specification states that a v4 block without a vote is invalid, therefore absent or invalid votes don't need to be considered. It is also suggested that miners should be allowed to explicitly vote for the status quo by indicating it in the coinbase (/BV/). The voting pattern may vary and miners can use different styles; /BV1234567/, /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, and the last one is 3MB. A message size limit is implemented to minimize the storage required per peer. If a 32MB block size is required, then each network input buffer must be at least 32MB. This makes it harder for a node to support a large number of peers. However, this could be solved by using a merkleblock message (or a different dedicated message) to send messages that only contain part of a block and have a limited maximum size. New hardLimit is calculated as the median of the current hardLimit multiplied by 1.2 or the 20-percentile (whichever is smaller), the current hardlimit, or the current hardLimit divided by 1.2 or the 80-percentile (whichever is higher). Votes are counted as abstains for the status quo, and votes that are out of range are considered to vote for the nearest in-range value. The raise value is defined as the vote for the 2400th highest block (20th percentile), and the lower value is defined as the vote for the 9600th highest block (80th percentile). If the raise value is higher than the status quo, then the new limit is set to the raise value. If the lower value is lower than the status quo, then the new limit is set to the lower value. Otherwise, the size limit is unchanged.
Updated on: 2023-06-10T21:56:50.023089+00:00