1. I think there is no need to have resolution at byte level, while resolution at MB level is not enough. kB would be a better choice.

2. In my specification a v4 block without a vote is invalid, so there is no need to consider absent or invalid votes

3. We should allow miners to explicitly vote for the status quo, so they don't need to change the coinbase vote every time the size is changed. They may indicate it by /BV/ in the coinbase, and we should look for the first "/BVd*/" instead of "/BVd+/"

4. Alternatively, miners may vote in different styles: /BV1234567/, /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"

Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

*

hardLimit floats within the range 1-32M, inclusive.

Does the 32MB limit actually still exist anywhere in the code?  In
effect, it is re-instating a legacy limitation.

The message size limit is 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.

There is no reason why a single message is used for each block.  Using
the merkleblock message (or a different dedicated message), it would
be possible to send messages which only contain part of a block and
have a limited maximum size.

This would allow receiving parts of a block from multiple sources.

This is a separate issue but should be considered if moving past 32MB
block sizes (or maybe as a later protocol change).

* Changing hardLimit is accomplished by encoding a proposed value
within a block's coinbase scriptSig.

* Votes refer to a byte value, encoded within the pattern "/BVd+/"
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
more than one match with with pattern, the first match is counted.

Is there a need for byte resolution?  Using MB resolution would use up
much fewer bytes in the coinbase.

Even with the +/- 20% rule, miners could vote for the nearest MB.
Once the block size exceeds 5MB, then there is enough resolution
anyway.

* Absent/invalid votes and votes below minimum cap (1M) are

counted as 1M votes. Votes above the maximum cap (32M) are counted
as 32M votes.

I think abstains should count for the status quo.  Votes which are out
of range should be clamped.

Having said that, if core supports the change, then most miners will
probably vote one way or another.

New hardLimit is the median of the followings:
min(current hardLimit * 1.2, 20-percentile)
max(current hardLimit / 1.2, 80-percentile)
current hardLimit

I think this is unclear, though mathematically exact.

Sort the votes for the last 12,000 blocks from lowest to highest.

Blocks which don't have a vote are considered a vote for the status
quo.

Votes are limited to +/- 20% of the current value.  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).

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.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev