BUIP005 (passed): Settings information via coinbase-txn & user-agent

[solex]

BUIP005: Settings information via coinbase-txn & user-agent
Proposer: Andrew Clifford

Submitted on: 31/12/2015
Revision 1, user-agent, 7/01/2016

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 Size and 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/

 

[Aquent]

Yup, that makes sense, so I vote in favour.

 

[solex]

@Aquent Thanks.
@theZerg as current lead developer will review first and then call for comment and members vote. We are hoping that this one goes smoothly as it will give very interesting information if and when BU miners start churning out blocks.

 

[theZerg]

1. EB (for EBS) Value in MB rounded to 1dp
2. ML (mining limit) Value in MB rounded to 1dp

I recommend we do not force rounding to 1 decimal pt. Invariably someone is going to not do that and some other client will choose to read it in some manner which breaks if it isn't done that way. Also, the purpose of rounding is to save bytes in the coinbase message which should be up to the miner (if it has available bytes, it could add more precision). Instead, let's say "optionally rounded down to the miners choice of precision". The DOWN part is very important -- all of these fields are limits so if a slightly lower limit than the actual is communicated its no problem as compared to reporting a higher limit than actual.

---

Also, what do you think about adding a paragraph along the lines of:

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.


I'm trying to head off criticism (probably mostly coming from outside) that we are making silly conceptual errors.

 

[Aquent]

"
Also, what do you think about adding a paragraph along the lines of:

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."

Wouldn't that miner need to have more than 51% of the hashing power for the dishonesty to have an effect? Otherwise they would be lying in regards to a higher limit, but I think we would probably expect the miners to track block usage, so probably most of them would set their limit just above actual demand, so being incentives to keep orphan rates down. These set soft and hard limits are just failsafes really against possible attacks as I doubt any miner would, right now for example, mine a block bigger than 2mb, or once we have demand at say 1.5mb mine a block bigger than 3mb etc...

 

[solex]

Thanks everyone for the likes and comments. I have incorporated @theZerg's paragraph which was needed and the clarification on rounding. Personally I think it likely that most of the known hashing power, the mining pools especially, will report accurately and that only a small % will report misleading numbers.

BU can function without this service by miners, so anything useful to come from it will be a bonus.

 

[theZerg]

Great! Let's open this up for public discussion.

 

[ladoga]

Every node owner could poll averages for EBS & EAD using bitcoin-cli?

 

[Peter R]

Great write up for the BIP, @solex! I think this is very important.

It all sounds very good. The one question I had was whether we wanted to define a way that miners could coordinate regarding changes to these parameters as well.

For example:

/ML2.0/EB3.5[8.0@400000]/AD4/

could mean that the miner intends to switch to 8 MB begining with block height 400,000.

 

[theZerg]

Does future intention matter? This field is not changing fast... why would we need to produce 8mb at block 400000 rather than 4000NN?

 

[Peter R]

"why would we need to produce 8mb at block 400000 rather than 4000NN?" -- @theZerg

What do you mean by "NN"?

 

[solex]

@Peter R
The principle of the idea is interesting, whether it would get much use is another question. There is an overlap with BIP100 where a miner signals a desire for a future limit by block vote e.g. /BV8.0/

I'm not sure that Jeff worried too much about how that would be handled without the miner having to change the source-code every time a vote needed updating. If BIP100 comes to be supported (as in BUIP002) then it can make use of a general argument "future block limit" which can be set by miners regardless as to whether they have BIP100 enabled or not. This value could be included as BV when BIP100 is enabled and/or the brackets qualifier when it is disabled.

edit: NN is just different digits. @theZerg is asking whether that much granularity of intent is needed, e.g. whether they would say 8MB at 400085 but not 400000

@ladoga
Yes this will likely be a future BUIP, although not much use at present when each BU node is surrounded by Core and XT nodes.

 

[solex]

The one question I had was whether we wanted to define a way that miners could coordinate regarding changes to these parameters as well.

I have been thinking about this because it could be a very useful facility in a BU majority network.

It needs to be consistent with the proposed support of the BIP100 emulation which also requires a tag in the coinbase-txn. The idea of a future limit is for mining nodes and should not really be mixed with the EBS which is intended for all nodes and to be generally higher than the prevailing mining limits.

Proposal:
That there are two new fields supported in the BU Interfaces as part of BUIP002 changes, this for the Settings>Unlimited window Mining tab::

• Future limit (maximum generated block size)
• Preferred Activation block height [only multiples of 12000 allowed)

If a miner does not have BIP100 activated the tag code FL (future limit) is used, so it becomes informational and not a vote.
When a miner has the BIP100 emulation activated the future mining limit is used to populate the BV (block vote) value, but only if the activation block height < previous miner vote count block height + 12000 (else FL is used). BIP100 vote counts are done every 12000 blocks. Because there is no initial mining threshold needed to trigger BIP100 itself in BU the vote counts always occur at block heights which are multiples of 12000.

The activation block height can then be reduced to an integer for the miner's coinbase-txn tag:

e.g. /FL5.0@2/

which is a future limit of 5MB at 2*12000 blocks after the most recent block height multiple of 12000 in the blockchain, i.e. the block of the previous BIP100 vote count + 24000

Examples:
So a non-voting miner could write the string:
/ML2.0/EB3.5/AD4/FL5.0@2/

Whereas a voting miner writes:
/ML2.0/EB3.5/AD4/BV5.0/

Votes are ignored where the block with the BV vote is larger than the MaxMinerVote from the previous BIP100 vote count.

This BIP100 info would need adding to BUIP002, as BUIP005 is just concerned with settings information reporting.

Thoughts...? Do people interested in this stuff agree that future limit info is a good idea?

 

[solex]

BU has recently hit 100 nodes and there is now some comment bubbling up on reddit about mining with BU and questions about the promised BU Mining Pool.

IMHO we need BUIP005 implemented soon, so that when blocks start appearing there is a growing historical data-set of miner settings which should eventually draw as much interest as the historical changes in difficulty.

I will update the BUIP to reflect the addition of a future mining limit, which does have potential benefit. There is no reason why working code cannot precede the BUIP vote, and this requirement has usually been encouraged for Core BIPs anyway.

 

[xd1gital]

is EB0.1 a valid value? or EB has to be >= 1 !

 

[solex]

@xd1gital

Yes. I just tried it and set my EBS to 100,000. So, EB0.1 is feasible.
Don't forget that BU is not a "big-blocks" client like XT, it is "freedom-blocks". If some users want a limit like 500,000 then they can set it and try and persuade everyone else what a good idea it is.

My gut feeling is that non-mining network consensus would be more like 5MB than 1MB, but we won't know for sure until BU goes past 50% (mining & nodes). The transparency provided by the user-agent setting will be very interesting.

 

[theZerg]

Low EBS is great for testing.

@solex can you fold in the proposal to also update the client string?

 

[TrevinHofmann]

@solex

Yes, even if the "official limit" isn't allowed below 1 MB, a miner majority could orphan anything above 100 KB with a soft fork today if they wanted to.

I'm all for maximizing the configurability. Let users reach their own consensus rather than pretending that a development team can accurately negotiate the wishes of a diverse user base.

 

[Lee Adams]

Solex Wrote:

"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"
​

I wonder a lot about this. It involves complex game theory and I do not think that miners will always have a mutual incentive to be honest. It may well be the case, but is there any way to prove this?

" orphaning a block from a particular miner does not increase the likelihood that other miners will subsequently mine a block -- block discovery is independent."
​

This seems wrong to me. Can you explain what I am missing? If I trick other miners into mining blocks that will not form the largest chain, surely they will have wasted their hashing power and I make a net gain by mining the longest chain.

Overall I am against this change for now as I think it distracts from the great points of BU and will give ammunition to the 'Schelling point' arguments being made by Adam Back.

 

[solex]

@Lee Adams
Thanks for your observations.

If I trick other miners into mining blocks that will not form the largest chain, surely they will have wasted their hashing power and I make a net gain by mining the longest chain.

There is no net gain because the difficulty only adjusts every 2016 blocks. This would be a weakness of alt-coins where difficulty adjusts on every block. Consider the degenerate case where all miners suddenly disappear except a single miner being left. There is no advantage for that miner because the PoW required for many blocks to come remains unchanged.

Going to your other point. This is basically the question of whether emergence of non-conscious high-order consensus (i.e. a double-blind where node A does not know node B settings and vice-versa) can be improved upon by conscious co-operation.

Certainly, conscious co-operation is not essential, however, in this implementation it should reduce the number of non-participating nodes who have seen an excessive block by narrowing the MGS and EBS ranges, i.e coalesce towards Schelling points.

There are 3 block size levels:
Average block-size of mined blocks
Consensus MGS as an effective mining block limit
Consensus EBS as an effective limit for block acceptance

So, a healthy state is ABS < conMGS < conEBS

It does not matter whether the network consensus drifts slowly through non-conscious interaction, or whether conscious co-operation creates Schelling points which causes punctuated consensus changes - as long as individual settings cluster towards the separate levels as above.