BUIP054: (closed) make AD optional and disabled by default

[freetrader]

Summary

Allow AD to be set to some value signifying infinity [1] (i.e. disable AD) which immediately discards excessive blocks and disables further processing of chains which would otherwise be considered due to containing excessive blocks.

The disabled setting is communicated in user agent and coinbase message by '/AD-/' string.

Alert the user to the presence of excessive blocks so that they can consider increasing their EB or re-activating AD in their configuration.

Motivation

While the Excessive Blocksize (EB) is easy to understand, the Acceptance Depth (AD) parameter has always been the subject of more debate and misunderstanding among BU users and those interested in BU's client technology.

Although intended (and functioning well) as a safeguard for node operators to stay on the longest valid chain automatically, independent of block size, some users would like the option to disable this feature entirely, creating a hard limit.

The author considers the "Unlimited" in BU to be about offering choices to the user, and so in that spirit they should have the option to configure a hard limit of their choice by setting AD to something that ensures that their client will not switch to a chain which exceeds their EB.

This "hard limit" logic is already implemented by other clients, e.g. Bitcoin Classic, which offer only Adjustable Blocksize Configuration without hopping chains after some AD threshold.

People of course ask what is additional benefit versus just setting AD to a very large value [2].

A technical benefit is that code in the client which handles excessive chains can be bypassed completely. Chains which are kept under consideration with a finite AD can now be discarded from processing.

A non-technical benefit is that it becomes clear that BU does not by itself intend to change the consensus rules - it is up to the users of the software to decide what to accept and they can express anything, including conformance to existing rules, simply though configuration.

Implementation

The client SHALL accept the following configuration values for excessiveacceptdepth in case-insensitive manner as signifying that AD is disabled:

• INF
• INFINITY
• INFINITE
• FALSE
• OFF
• DISABLED

If the configuration of the client does not specify otherwise, the client SHALL assume excessiveacceptdepth=INF as the default setting.

The client shall represent the disabled setting in user agent and coinbase messages (if enabled) by '/AD-/' string (that is 'AD' followed by a hyphen, ASCII code 0x2d).

Blocks which exceed the software's effective EB SHALL be rejected as invalid if AD is set to disabled.

A peer which sends an excessive block to a node configured with disabled AD SHALL be subjected to Denial-of-Service score increase / potential banning.

NOTE: The original code bans clients producing excessive blocks immediately - whether this is desirable or should be subject to additional user configuration is up for discussion and not yet determined by this BUIP.

The operator SHALL be warned of excessively sized blocks being rejected, by

• a warning message in the log file (the original bad-blk-length error message is re-introduced). This log message could be rate-limited to a certain maximum number of messages per day, to avoid the log being spammed.
  
• a warning message in the status bar for GUI users
  
• an event notification via ZMQ

Other recommendations

If AD is disabled by default, the client SHOULD always be released with a default EB value significantly above the current average blocksize (at least x4 the average over the last retargeting period before a release is cut).

References

[1] https://bitco.in/forum/threads/interest-in-infinity-patch-for-bu.1618/
[2] Current maximum AD is 2^32, or equivalent to 81,715 years at 10 minutes / per block average

 

[freetrader]

It has been suggested by @Tom Zander on Slack to add 'false' to the list of values which disable AD.
I propose 'off' and 'disabled' as well.
It's not really a big downside that a user would try 'true', 'on' or 'enabled' - in that case the software should just give a useful error message on startup, explaining the valid value range and pointing the user to some more documentation so that they can understand what they are doing.

Updated the BUIP.

 

[AdrianX]

I agree changes to AD is an opportunity to clear some FUD and should be addresses.

Some considerations:

Mining nodes are unaffected by AD so it should be off by default if mining is enabled.

Regarding relay nodes and AD:

If AD is infinite of false by deftly why recommend a block limit? - why should the block limit not be infinite?

Can someone list the justifications to limit block size?

AD gives miners insight as to how hard the EB limit is. A miner can calculate the probability of propagating a block above the network EB limit if they have AD info. evidence suggests most industry node operators (the key relay nodes) are too stupid to limit block size, evidence of this can bee seen in the last 3 years of FUD including letters of intent and propaganda used to justify keeping a limit.

Unless there is a good reason to have these nodes justify a limit to transaction volume and dictate it to miners I don't think it should encouraged.

The bitcoin white paper describes this behavior: "they [mining nodes] work on the first one [block] they received, but save the other branch in case it becomes longer."

"The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

Given relay nodes do not work but follow they switch to the longest branch of valid blocks. AD is a just definition for this behavior.

AD is a use defined definition for longest branch, a user should enable this feature if they introduce an arbitrary transaction limit defined as a block data limit. - if there is no limit there is no AD. If there is an arbitrary limit, that's not a bitcoin rule, then a longest chain definition is needed.

BU is consistent with this concept, and applies it to relay nodes.

[Mining] Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.

When catering to relay node users it is worth considering that hidden nodes are a burden on the network they consume resonators they do not relay transactions, and as their contribution can't be measured we should not optimist for such nodes. people running such nodes can compile their own code, or rather they should switch to a SPV node concept still to be developed)

 

[awemany]

@freetrader: What is the reason to allow multiple different strings for infinity? This appears to create complexity for no reason?

 

[freetrader]

The different strings are only on the configuration side, so it wouldn't affect other systems, the complexity is only on testing that a few more strings are accepted.

The effort lies in supporting a configuration item that can be a string OR a number (not sure if we have something like that already). Once we set that up we might as well allow some reasonable strings that a user would guess.

 

[awemany]

@freetrader: Ah ok fair enough, I misunderstood. Thank you.

 

[freetrader]

No, the BUIP is a little unclear on those parts. I'll try to fix it

EDIT: also simplified the title to remove the scary confusing infinity from it

 

[Roy Badami]

Originally I was against the idea of the "infinity patch", but that's because the only argument I'd seen put forward was about some meaningless (IMO) philosphical difference between "a very long time" and "forever".

I'd actually been thinking for some time that being able to disable the AD functionality for users who don't need/want it (or who just want to minimise the amount of new code they're running) would be a good thing.

I'm wondering whether we really want to advertise "AD-" though. It doesn't really mean anything - it's certainly not a promise never to accept bigger blocks than EB. If external governors come into being, it may not even always be a promise not to accept bigger blocks without human intervention.

I'm open to arguments, but I think right now my preference is to just not advertise AD at all if the AD functionality is disabled in the Client. There's no need to distinguish between having AD disabled, and a client (like Classic) that doesn't implement AD at all. (But possibly this feeds into the whole debate about whether we should be advertising AD at all, even when it is enabled...)

 

[freetrader]

@Roy Badami : my take on the advertising of AD is that it should be optional in any case, but I don't want to make that the subject of this PR, nor force the client to not show it if AD is turned off.

Consider the /AD-/ in this BUIP to just mean "whenever the client *would* output something to reflect this state, that is what is should output".

For some people, turning off AD could well mean "I never want to accept a bigger block".
I'm not at all against people hiding whatever information they please.

There should be another BUIP as far as I'm concerned, which gives users proper tools to choose whether to display such data that is reflected on external interfaces (useragent, coinbase string etc). This control of output should essentially be done on a different level than what this BUIP tackles.

I would be grateful if someone else raised a BUIP to give finer grained control of such parameter advertisement.

---

@AdrianX : I agree with you that AD seems more useful for relay nodes. This BUIP does propose to turn it off completely by default, which would force relay node operators to make a conscious choice about what AD they would be willing to tolerate, if they turn it on. A guideline should accompany the description of how AD operates, this could recommend e.g. the current default of 12 to relay node operators who don't hold a strong opinion.

 

[Roy Badami]

Advertising it is harmless, so I'm OK with punting that question to a separate BUIP.

 

[theZerg]

I think that AD is extremely important to ensure that the blockchain converges, so I personally favor leaving AD exactly as is. BU IS about choice and setting AD very high IS a valid choice. But I do not see why we should encourage or simplify behavior that would cause a user to not follow the hash rate majority.

Regardless of my opinion, I'm releasing this BUIP for discussion and voting...

 

[Roy Badami]

@theZerg We are where we are and there are people who don't trust our code anymore. Regaining that trust will take time, but allowing users to disable BU-specific codepaths where it makes sense to provide that option is one thing we can do right now.

 

[JAFO]

I support this BUIP. AD causes confusion IMHO. I would even support it's removal entirely.

 

[Tomas van der Wansem]

The different strings are only on the configuration side, so it wouldn't affect other systems, the complexity is only on testing that a few more strings are accepted.

I like this BIP but I find the idea of using multiple strings rather strange. Sure it is not more complex to program, but it is only confusing to the user even if it is only for configuration. If I see AD=INF all the time, then I will have to look up what AD=FALSE is.

It makes documentation, samples, and comparisons more confusing, and I don't really understand the benefit compared to defining one string.

 

[seweso]

Yes. AD should be an option to keep miners in check. It makes less sense for nodes who want to enforce a hard limit economically.

 

[Peter R]

The reason I voted against this BUIP was because it indicated that AD would be OFF by default. I think it would be great to have a more explicit way to turn AD off, however. Maybe retry with AD on by default?

 

[freetrader]

Thanks for the feedback @Peter R . @Christoph Bergmann expressed the same opinion.
If more people feel that the default should be on , but with an easy way to disable it, then I will consider amending this BUIP and re-submitting for the next round.

Are there any who have voted for it now, who would NOT vote for it if I changed it like that?

 

[solex]

I also thought that it would be default off.
I would have been fairly happy with default as currently, and a simple check-box in the GUI to disable AD, plus a single CLI arg to disable (wasn't happy with the big list either).

 

[AdrianX]

I would like to see MG "off" by dealt (Maximum Generation Size needs to be enabled in order to mine - dealt is 1MB)

I would like to see EB "16" by default if MG is disabled.

I would like to see EB "off" by default if MG is enabled. i.e. unlimited (miners can enable their own polities)

I would like to see AD On and "set to a default** if MG is not enabled.

I would like to see AD "off" by default if MG is enabled .

so if mining is disabled then AD should be on by default. (user can set a Hard limit by setting EB and turning AD off)



**I would like AD default to be a much lower value than we have at present.

Someone who has more math ability than I can work out the probability of less than 50% of the hash-rate mining more than 50% of 144 blocks in any period of 144 blocks. I'd set the default AD to be high enough to follow the greater than 50% hash-rate if it had bad luck in a 144 block period. and then +1

I'd vote for this BUIP if the above were active.

It would solve every objection made in opposition to BU and give users the ability to set what what they want.

 

[Mengerian]

For me, the most important part is to be able to set AD to "off"

The second most important thing for me, is I'd like the software not to advertise AD in the User Agent String and coinbase by default.

The default for AD, whether on or off, is not important to me.