Luke Dashjr via bitcoin-dev
2016-12-15 01:48:23 UTC
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
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
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
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
new max block size = 1,000KB + (average size of last 2016 blocks - 750KB)
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.
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
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
new max block size = 1,000KB + (average size of last 2016 blocks - 750KB)
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.