BUIP054: Make AD optional and disabled by default
Proposer: freetrader
Submitted on: 2017-05-05
Status: closed


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

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

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 for
excessiveacceptdepth in case-insensitive manner as signifying that AD is

  • INF
  • OFF

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

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,

  • 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
  • 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).



[2] Current maximum AD is 2^32, or equivalent to 81,715 years at 10
minutes / per block average