login
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/

  1. 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)/

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/