Skip to content

Latest commit

 

History

History
65 lines (62 loc) · 5.67 KB

005.mediawiki

File metadata and controls

65 lines (62 loc) · 5.67 KB
Raw

BUIP005: Settings information via coinbase-txn & user-agent
Proposer: Andrew Clifford
Submitted: 2015-12-31 (Revision 1, user-agent, 2016-01-07)
Status: passed
Summary
The Bitcoin Unlimited 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.

Mining nodes also use the Maximum Generate Size (MGS) for their mining block limit. It is usually set smaller than the EBS. BUIP002 will propose the addition of a Future Generate Sizeand Proposed Activation Block Height (FGS & ABH) where miners can signal their intention to increase (or decrease) their mining limit in the future. The ABH is always a multiple of 12000. It is considered that miners should not need to co-ordinate MGS changes more frequently than every 12 weeks.

While these settings are individual, and will vary, the network benefits when values are more consistent across many nodes. Consistency reduces the number of nodes which are not fully participating in the network where they have recently received an excessive block.

Two methods for increasing transparency, apart from adding message types for polling nodes, are proposed here. First, for miners to reveal their settings in mined blocks. Secondly, for both mining and non-mining nodes to reveal their excessive block settings in the user-agent subversion string which qualifies the software identifier, "BitcoinUnlimited", to connecting peers. All BU full node owners are incentivized to allow the software to do this because a healthier network supports a higher BTC price and this provides higher revenue for miners, and capital gain for non-miners.

It is considered that the use of the user-agent is appropriate for individiualized settings which feed into a high-order network consensus.

In reality, the settings information reported on some blocks may be deliberately erroneous.
Users of these fields must understand that they are not authoritative -- a miner could lie about these limits. However, miners have a mutual incentive to be honest because orphaning a block from a particular miner does not increase the likelihood that other miners will subsequently mine a block -- block discovery is independent. Lying would only affect other miner's profitability long term via the difficulty adjustment process (orphans are not counted when difficulty is calculated). But a miner lying about block size acceptance will only work once, so the actual effect on the difficulty will be negligible.
Similarly, some node owners may provide spurious excessive block setting information in the user-agent, requiring filtering out by up-time, ip-address duplication, etc to improve results.

Websites such as bitcoinunlimited.info can show analysis of these metrics so that BU users may choose their EBS & EAD settings more consistently with the network as a whole. Similarly miners can make their MGS setting more consistent.

 The following extension is proposed for the Bitcoin client:
1. That by default the BU mined blocks carry excessive settings information in the txn-input (scriptSig) of the coinbase-txn (which carries the miner reward).

Delimiter '/' (forward-slash), flexible ordering, see note (i) for Float representation

  1. AD (for EAD) Integer
  2. BV (for FGS if BIP100 emulation active) Float, see note (ii)
  3. EB (for EBS) Float
  4. FG (for FGS if BIP100 emulation inactive [default]) Float, see note (iii)
  5. MG (for MGS) Float
Example: /MG2.0/EB3.5/AD4/

It is recommended that this comprise one commit "BUIP005 Settings info coinbase"


2. That by default the BU user-agent subversion carry the excessive block settings EB & AD, which are defined above. The subversion format adheres to the recognized convention of using parentheses, and a ';' (semi-colon) delimiter. AD values >9999999 to be shown as that value (about 190 years of blocks).

Example: /BitcoinUnlimited:0.11.2(EB3.5;AD4)/

It is recommended that this comprise one commit "BUIP005 Settings info user-agent"


Note (i)
Float numbers
While BU allows for larger blocks it strongly adheres to the convention that block-space should not be wasted. Settings information is to be efficiently represented by default while preserving human readability. So, float values are in megabytes rounded down to 1dp. Miners may optionally change this to provide greater precision. If a float value is parsed >= 100,000 then it should be assumed as bytes.

Note (ii)
BIP100 Block Votes
The BIP100 emulation defined in BUIP002 makes use of the FGS for block voting where a vote count occurs at block numbers which are multiples of 12000. BV tag is written if BIP100 activated & ABH == next block for BIP100 vote counting, otherwise an FG tag is written.
BV and FG are mutually exclusive

Example: /MG2.0/EB3.5/AD4/BV5.5/

Note (iii)
FG value qualification
Future generate size may be suffixed with a qualifier to represent the Proposed Activation Block Height. The qualifier begins "@" (at symbol) and is (ABH - current blockchain height) / 12000 rounded up to 0dp. Results <=0 are ignored, and no FG tag is written if FGS == 0.

Example: /MG2.0/EB3.5/AD4/FG5.5@3/