Skip to content

Latest commit

 

History

History
202 lines (148 loc) · 7.66 KB

002.md

File metadata and controls

202 lines (148 loc) · 7.66 KB
Raw
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:

  • <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 previous 12,000 blocks. EAD=5259601

  • 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, EAD=5259603

  • 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 bytes per 10 minutes, EAD=5259605

  • BIP248

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

  • BitPayAdaptive

BitPay developers (pending formal specification) MGS=soft_limit, EBS=hard_limit, EAD=5259607

  • 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.
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:​

Mining nodes which activate BIP100 are choosing to update their own mining limit (maxGenerateSize) to the new MinerVoteResult
Non-mining nodes which select BIP100 are choosing to update their Excessive Block Size to the MinerVoteResult.

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.