From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 specification
Date: Thu, 3 Sep 2015 12:59:01 +0100 [thread overview]
Message-ID: <CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com> (raw)
In-Reply-To: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 2812 bytes --]
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 1.
>
> 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).
>
> 1. Changing hardLimit is accomplished by encoding a proposed value
> within a block's coinbase scriptSig.
> 1. Votes refer to a byte value, encoded within the pattern
> "/BV\d+/" 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.
> 1. 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.
[-- Attachment #2: Type: text/html, Size: 4706 bytes --]
next prev parent reply other threads:[~2015-09-03 11:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 3:33 Jeff Garzik
2015-09-03 4:45 ` Dave Scotese
2015-09-03 7:57 ` jl2012
2015-09-03 11:20 ` Btc Drak
2015-09-03 14:34 ` Jeff Garzik
2015-09-03 15:58 ` Btc Drak
2015-09-03 16:13 ` Jorge Timón
2015-09-03 11:59 ` Tier Nolan [this message]
2015-09-03 16:32 ` jl2012
2015-09-03 16:35 ` Jeff Garzik
2015-09-03 17:32 ` Btc Drak
2015-09-03 17:52 ` Peter Todd
2015-09-04 7:53 ` Andy Chase
2015-09-04 15:37 ` Simon Liu
2015-09-04 15:40 ` Btc Drak
2015-09-03 14:35 ` Jeff Garzik
2015-09-03 19:40 ` Simon Liu
2015-09-03 20:15 ` Oliver Petruzel
2015-09-03 20:34 ` Dave Scotese
2015-09-04 3:50 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox