BUIP002: Multi-BIP Scaling Enabler
Proposer: Andrew Clifford
Submitted: 2015-12-30
Status: passed
Summary
The first version BU client for full-node owners has user configurable
settings for the Excessive Block Size and Excessive Acceptance
Depth (EBS & EAD) which are the low-level rules implemented by BUIP001.
When used in the Bitcoin network an emergent block size limit becomes
effective across all connected nodes.
Ironically, the complete flexibility of this solution may put off many
potential new users who would prefer their settings to reflect the same
as an existing Bitcoin Improvement Proposal (BIP) proposed for Bitcoin
Core by a noted cryptocurrency expert. These are either not yet
implemented, or implemented just in the XT client (BIP101). A number of
BIPs have wide recognition and conceivably a significant portion of the
BU network user-base may select a single BIP which determines the
emergent block limit. Notably they all have programmatic nuances and are
not able to be replicated with the low-level BU settings (by set and
forget), except for the Bitcoin Core 1MB fixed-limit which is offered
for the sake of completeness.
The final list of supported BIPs will be at the discretion of the BU
lead developer.
The publicity and public relations initiative gained from allowing users
to select and use their preferred BIP is potentially a significant
benefit to BU, especially as the BIPs were proposed to be universal in
the Core and XT clients. Mining-power may be attracted as many miners
like both BIP100 and BIP248.
The following extensions are proposed for the Bitcoin client:
Section A : Interface Changes
1. Addition of the label “Bitcoin Core BIP Implementation” and an
associated drop-down box in the Settings>Unlimited window Network
tab. The drop-down list will initially comprise just the deactivation
setting, which leaves the existing EBS & EAD settings fully usable:
This setting is the only one visible unless the user selects the
drop-down which is populated with the short-names of the BIP
Implementations which have been committed separately. The recommended or
working BIP list and their short-names appears in Section B.
If one of the BIPs is selected the drop-down closes and both the EBS &
EAD fields are greyed and blanked. Neither can be updated.
Internally EAD defaults to 5259600, which is 100 years, + a sequence
number which may help with transparency of BIP popularity when
signalling channels are available.
However, a new check-box is available, default unchecked, “Enable BU
acceptance depth” which will then make the EAD modifiable again, and the
user may enter a low value as an override.
“Future Generated Size”
“Preferred Activation Block Height” [only multiples of 12000 allowed)
Both are used for BUIP005 information & BIP100 Block votes
Command line support
utilizes short-names in lowercase e.g. -bip101
Remote Procedure Call support.
It is recommended that all the above comprise a single commit to the
Bitcoin Unlimited repository. “BUIP002 Interfaces”
Section B : BIP Implementations
Most scaling BIPs have incomplete specifications, have either no
official number, not been formally proposed, or are withdrawn.
Recognizing that most may never have a complete specification the
working principle here is to adhere to the latest modifications
announced by the original authors. Although BIP100 is withdrawn by its
author it is included here as it was, for a while, the BIP of preference
by >50% of the Bitcoin network hashing power.
BIP short-names are in italics. The long-name description with the
author and technical detail is best collated into an informational page
on the bitcoinunlimited.info website for user reference.
Some BIPs may be dropped while others are added by the BU lead developer
during the development phase of BUIP002:
5. BIP Recommended or Working List.
Jeff Garzik (formally withdrawn) miner vote of voting blocks from
previous 12,000 blocks. EAD=5259601
Gavin Andresen (existing implementation: XT) 8MB doubling bi-annually
for 20 years from 1st Aug 2015, smoothed, EAD=5259602
Jeff Garzik (formal specification) 1MB, then 2MB from 5th May 2016,
EAD=5259603
Pieter Wuille (informal specification) 1MB increasing at 4.4% per 97
days from 1st Jan 2017 until July 2063, stepped, EAD=5259604
Jeff Garzik (formal specification) 1MB, then 2MB at 5th May 2016 +20
bytes per 10 minutes, EAD=5259605
Adam Back (informal specification) 2MB, then 4MB from 25th Aug 2017, 8MB
from 25th Aug 2019, EAD=5259606
BitPay developers (pending formal specification) MGS=soft_limit,
EBS=hard_limit, EAD=5259607
Satoshi Nakamoto (existing implementation: Core) 1MB fixed, EAD=5259608
For the avoidance of doubt, in every BIP, any reference to the maximum
block size is implemented as the “excessive block size” in Bitcoin
Unlimited.
It is recommended that each BIP Implementation comprises a single commit
to the Bitcoin Unlimited repository. e.g. “BUIP002 BIP101”
BIP100 details
As BIP100 is withdrawn a few implementation details are tailored for BU.
Because there is no initial mining threshold needed to trigger BIP100
itself in BU, for this implementation a vote count occurs at block
height multiples of 12,000 (about every 12 weeks). One block vote is
cast in each block.
The original proposal for 20th percentile is replaced here with MEDIAN.
Voting:
A miner votes by setting the Future Generate Size and this is used in
the coinbase scriptSig, e.g. /BV3/ but only if their Proposed Activation
Block Height < previous miner vote count block height + 12000, i.e. a
desire to increase the max generate size within the next 12000 blocks.
If no FGS value or the ABH is too far in future then BV vote is set to
PreviousMinerVoteResult.
Counting:
Only a subset of the previous 12,000 blocks are expected to have
votes.
Votes are ignored where the block with the BV vote is larger than the
MinerVoteResult from the previous BIP100 vote count.
A BV number < 100 000 is seen as MB, a number larger is bytes.
Floor=0.5*PreviousMinerVoteResult
Ceiling=2*PreviousMinerVoteResult
Votes outside floor or ceiling are brought in and all votes sorted.
MinerVoteResult = median value of the votes (this was originally 20th
percentile, but median is considered better where BIP100 is opt-in)
Adherence:
Note i) BIP Mining thresholds are not used because there is no
requirement for a universal implementation. This decision is devolved to
the individual users in BU.
Note ii) For blocks >1MB the SIGOPS counting and limiting will follow
BIP101’s methodology for all the BIP implementations.
Note iii) If a future commit is made to Bitcoin Core for one of the
scaling BIPs already applied to BU, and there are differences in the
implementation, then a new BUIP may be required to synchronize BU with
the Core implementation of the BIP concerned.