From: Luke Dashjr <luke@dashjr.org>
To: "t. khan" <teekhan42@gmail.com>
Date: Thu, 15 Dec 2016 01:48:23 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.36-gentoo-r1; KDE/4.14.24; x86_64; ; )
References: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>
In-Reply-To: <CAGCNRJrkGHnnq_s3rsUJH7TX+JB8Ue28SjoyxBnW+LGpH6iJnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201612150148.23862.luke@dashjr.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - Block75 - Managing max block size as we do
	difficulty
Precedence: list

Please use ASCII quotes in the Title. It is also too long (max size 44=20
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 t=
he=20
maximum block size, but the specification only affects MAX_BLOCK_BASE_SIZE,=
=20
which does not actually affect the max block size at all. Either the=20
specification needs to implement the described goal (adjusting max block si=
ze)=20
or the motivation needs to be adjusted to explain why MAX_BLOCK_BASE_SIZE i=
s=20
being adjusted.

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

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

When you're ready, feel free to open a pull request on=20
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,
>=20
> Following is a BIP for submission. Please let me know if any
> modifications/additions are required.
>=20
> Thank you,
>=20
> -t.k.
>=20
> --------
>=20
> BIP: ??
> Title: =E2=80=98Block75=E2=80=99 - Managing max block size the same way w=
e do difficulty
> Author: t.khan <teekhan42@gmail.com>
> Created: 2016-12-13
>=20
>=20
> 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. Th=
is
> would be done on the same schedule as difficulty.
>=20
>=20
> 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=E2=80=99t involved,  except =
for
> setting the original target of a 10 minute per block average, and therefo=
re
> it isn=E2=80=99t political or contentious. It=E2=80=99s simply a response=
 to changing
> network resources.
>=20
> 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 si=
ze
> or transaction fees.
>=20
> It=E2=80=99s clear at this point that human beings should not be involved=
 in the
> determination of max block size, just as they=E2=80=99re 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.
>=20
> A permanent solution that is simply a response to changing transaction
> volumes is the goal of Block75.
>=20
>=20
> Specification
> The max block size would be recalculated every 2016 blocks, along with
> difficulty, using this simple formula:
>=20
> new max block size =3D 1,000KB + (average size of last 2016 blocks - 750K=
B)
>=20
> Further details:
>=20
> MAX_BLOCK_BASE_SIZE =3D 1000000 //this line stays the same
> TARGET_CAPACITY =3D 750000 //new line representing 75%
>=20
> AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus
> TARGET_CAPACITY
>=20
> To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE + AVERAGE_OV=
ER_CAP)
>=20
>=20
> 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.
>=20
> The 2016 blocks (two week) period was selected as it has been shown to be
> reasonably adaptive to changing network resources. The frequent and gradu=
al
> adjustments that result from this will be relatively easy for miners and
> node operators to predict and adapt to, as any unforeseen consequences wi=
ll
> be visible well in advance. It also minimizes any effect a malicious party
> could have in an attempt to manipulate block size.
>=20
> Copyright
> This work is placed in the public domain.