[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [bitcoin-dev] BIP - Block75 - Managing max block size as we do difficulty
From:       luke () dashjr ! org (Luke Dashjr)
Date:       2016-12-15 1:48:23
Message-ID: 201612150148.23862.luke () dashjr ! org
[Download RAW message or body]

Please use ASCII quotes in the Title. It is also too long (max size 44 
characters).

Add missing headers:
  Layer: Consensus (hard fork)
  Comments-Summary: No comments yet.
  Comments-URI: TBD
  Status: Draft
  Type: Standards Track
  License: PD

It must be made at least technically sound. The BIP talks about adjusting the 
maximum block size, but the specification only affects MAX_BLOCK_BASE_SIZE, 
which does not actually affect the max block size at all. Either the 
specification needs to implement the described goal (adjusting max block size) 
or the motivation needs to be adjusted to explain why MAX_BLOCK_BASE_SIZE is 
being adjusted.

It is missing a section on Backward Compatibility. This should address at 
least the fact that this is *NOT* backward compatible, and ideally propose a 
mechanism for establishing agreement from the entire community for its 
deployment. Similarly, there is talk of 75%, but the algorithm presented does 
not in fact implement 75%.

Finally, I am about to set BIP 2 to Active, so it would be preferable to 
choose a copyright license from the choices in BIP 2.

When you're ready, feel free to open a pull request on 
https://github.com/bitcoin/bips/ with the BIP in mediawiki format, named:
    bip-tkhan-block75.mediawiki

Thanks,

Luke


On Wednesday, December 14, 2016 7:55:20 PM t. khan wrote:
> Hi Luke,
> 
> Following is a BIP for submission. Please let me know if any
> modifications/additions are required.
> 
> Thank you,
> 
> -t.k.
> 
> --------
> 
> BIP: ??
> Title: ?Block75? - Managing max block size the same way we do difficulty
> Author: t.khan <teekhan42 at gmail.com>
> Created: 2016-12-13
> 
> 
> Abstract
> Automatic adjustment of max block size with the target of keeping blocks
> 75% full, based on the average block size of the previous 2016 blocks. This
> would be done on the same schedule as difficulty.
> 
> 
> Motivation
> The every two-week and automatic adjustment of difficulty has proven to be
> a reasonably effective and predictable way of managing how quickly blocks
> are mined. It works well because humans aren?t involved,  except for
> setting the original target of a 10 minute per block average, and therefore
> it isn?t political or contentious. It?s simply a response to changing
> network resources.
> 
> Bitcoin needs a reasonably effective and predictable way of managing the
> maximum block size, which both allows moderate growth and keeps max block
> size as small as possible, thereby preventing wild swings in max block size
> or transaction fees.
> 
> It?s clear at this point that human beings should not be involved in the
> determination of max block size, just as they?re not involved in deciding
> the difficulty. Any solution to block size scaling which sets an arbitrary
> max block size (1MB, 2MB, 8MB, etc.) is by its very design a temporary
> solution and should be avoided. Any solution which passes the decision on
> to miners/pool operators for a vote will, by its very design, be political
> and contentious and should be avoided.
> 
> A permanent solution that is simply a response to changing transaction
> volumes is the goal of Block75.
> 
> 
> Specification
> The max block size would be recalculated every 2016 blocks, along with
> difficulty, using this simple formula:
> 
> new max block size = 1,000KB + (average size of last 2016 blocks - 750KB)
> 
> Further details:
> 
> MAX_BLOCK_BASE_SIZE = 1000000 //this line stays the same
> TARGET_CAPACITY = 750000 //new line representing 75%
> 
> AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> TARGET_CAPACITY
> 
> To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
> 
> 
> Rationale
> The 75% full block target was selected as it represents the middle ground
> between blocks being too small (average 100% full) and blocks being
> unnecessarily large (average 50% full). It can absorb short-term spikes in
> transaction volume of up to 33% and also limits the growth of max block
> size to 250KB over the previous period.
> 
> The 2016 blocks (two week) period was selected as it has been shown to be
> reasonably adaptive to changing network resources. The frequent and gradual
> adjustments that result from this will be relatively easy for miners and
> node operators to predict and adapt to, as any unforeseen consequences will
> be visible well in advance. It also minimizes any effect a malicious party
> could have in an attempt to manipulate block size.
> 
> Copyright
> This work is placed in the public domain.

[prev in list] [next in list] [prev in thread] [next in thread]