From: Luke Dashjr <luke@dashjr•org>
To: "t. khan" <teekhan42@gmail•com>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - Block75 - Managing max block size as we do difficulty
Date: Thu, 15 Dec 2016 01:48:23 +0000 [thread overview]
Message-ID: <201612150148.23862.luke@dashjr.org> (raw)
In-Reply-To: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>
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@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.
parent reply other threads:[~2016-12-15 1:48 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>]
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=201612150148.23862.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=teekhan42@gmail$(echo .)com \
/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