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

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:

• <none>

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.

1. Addition of two labels and fields on the Settings>Unlimited window
Mining tab:

“Future Generated Size”
“Preferred Activation Block Height” [only multiples of 12000 allowed)​

Both are used for BUIP005 information & BIP100 Block votes

1. Command line support
utilizes short-names in lowercase e.g. -bip101

2. 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.​

• BIP100

Jeff Garzik (formally withdrawn) miner vote of voting blocks from

• BIP101

Gavin Andresen (existing implementation: XT) 8MB doubling bi-annually
for 20 years from 1st Aug 2015, smoothed, EAD=5259602

• BIP102

Jeff Garzik (formal specification) 1MB, then 2MB from 5th May 2016,

• BIP103

Pieter Wuille (informal specification) 1MB increasing at 4.4% per 97
days from 1st Jan 2017 until July 2063, stepped, EAD=5259604

• BIP202

Jeff Garzik (formal specification) 1MB, then 2MB at 5th May 2016 +20

• BIP248

Adam Back (informal specification) 2MB, then 4MB from 25th Aug 2017, 8MB

BitPay developers (pending formal specification) MGS=soft_limit,

• Core1MB

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”

## **BIP Specification Notes: ** Flag dates trigger at 0:00 UTC

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 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)

## BIP102 flag date BIP102 was intended to start on 11th November, 2015, but if this were to be implemented by Core it would likely match the date proposed for BIP202.

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.