excessiveacceptdepth

INF

INFINITY

INFINITE

FALSE

OFF

DISABLED

excessiveacceptdepth=INF

'/AD-/'

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.



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

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.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.The client SHALL accept the following configuration values forin case-insensitive manner as signifying that AD is disabled:If the configuration of the client does not specify otherwise, the client SHALL assumeas the default setting.The client shall represent the disabled setting in user agent and coinbase messages (if enabled) bystring (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 operator SHALL be warned of excessively sized blocks being rejected, byIf 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).[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