Merge branch 'convert-to-md-2' into 'master'

Convert BUIPs from mediawiki to gfd mark up language

See merge request bitcoinunlimited/BUIP!99

001.md

@@ -0,0 +1,72 @@
+    BUIP001: Extensions to the Bitcoin Client
+    Proposer: Andrew Stone
+    Submitted: 2015-11-26
+    Status: passed
+
+The following extensions are proposed for the Bitcoin client:  
+
+1. GUI: Creation of a “Bitcoin Unlimited” menu option and dialog box to
+access BU specific features. This menu option will appear just below the
+“options” option.  
+
+2. Addition of an Unlimited Dialog / command line option to change the
+maximum size of a generated (mined) block. This will allow miners to use
+BU to generate large blocks. The default value will be 1000000 bytes
+(compatible with today's consensus).  
+
+3. Addition of an Unlimited Dialog / command line option to change the
+default block “accept” size. Blocks larger than this (excessive blocks)
+will only be accepted if they are N deep in the blockchain. This will be
+16MB by default. The largest message is limited to 10 times this size,
+to that creates an effective block size limit. This limitation was not
+removed entirely to stop people from DOSing BU by sending a fake
+infinitely sized block.  
+
+4. Addition of an Unlimited Dialog / command line option to set the
+excessive block accept depth. This is the N parameter in the description
+of \#3. The default value will be 4.  
+
+5. Addition of traffic shaping. Traffic shaping, similar to what is
+merged into Bitcoin XT is added to the Unlimited menu and command line
+options. As blocks grow bigger, it is important that users can easily
+configure how much bandwidth should be used for Bitcoin. This allows the
+Bitcoin client to run unobtrusively in a home network. Although
+bandwidth-limited clients in theory increase the time it takes for a
+block to propagate through the network, this will only happen if their
+removal would partition the network – i.e. they are a critical node in
+the network topology. Additionally, they are valuable as another copy of
+the blockchain and to serve data to clients who do not need fast block
+propagation (essentially everyone but miners). And in practice, Matt
+Corollo's Bitcoin Relay Network is used for fast block propagation...  
+
+6. Fix in the GUI's transaction notification – if lots of notifications
+are coming in, some will be skipped. This fixes the problem where if you
+end up receiving 1000+ transactions the visual notifications keep coming
+for a half hour after the actual notification.  
+
+7. Client identifier changed to BitcoinUnlimited  
+
+8. Block version changed to 0x40000007. This version would reflect
+BIP101 and OP\_CHECKLOCKTIMEVERIFY support.  
+
+9. Minimal branding changes -- replacing Unlimited with Core in key
+locations and adding new artwork. We want to rebrand, but do not want
+rebasing the code to be a headache. So a minimal approach was taken WRT
+branding.  
+
+
+A release will be made containing the above changes based off the
+Bitcoin Core 0.11 (.2) branch. Subsequent Bitcoin Unlimited releases
+will also include the above changes.  
+
+These changes are functionally complete on the 0.11cfg\_stats, and have
+been running on mainnet and testnet for several days. However, this
+branch will still get a final code review, hopefully by a different
+developer before release (you are NOT voting to include this branch "AS
+IS").  
+
+It is important that we make an initial, simple Bitcoin Unlimited
+release to get things going. Please do not bikeshed this proposal with
+small modifications and new features (for example, having a button that
+automatically tracks BIP101 block expansion). We can make things better
+in subsequent releases.

002.md

@@ -0,0 +1,202 @@
+    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.  
+
+2. 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  
+
+3. Command line support  
+utilizes short-names in lowercase e.g. -bip101  
+
+4. 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.