Thinking more about this, it seems to me that the two really important settings that BU enables are the Excessive Block (EB) size and the Maximum Generation size (MG). The Accept Depth (AD) parameter should really be thought of as a quick-and-dirty “fail-safe” that (to repeat myself) reflects the basic reality that you should be prepared to revise your predictions about what others will accept based on changed evidence of what they are actually accepting. It’s probably “good enough” for most non-mining nodes. And for mining nodes, the Accept Depth parameter is probably unlikely to play much of a role--at least if we imagine that, in practice, most increases in “the limit” will be well coordinated by major miners and economically-significant node operators (e.g., major wallets and exchanges). Plus, in the event that a miner
does experience an “Accept Depth event,” they’re almost certainly going to want to “switch to manual” and tweak their settings in response (and they have huge incentives to monitor the network pretty damn closely). Having said that, it may be the case that some nodes or miners will want to deploy their own more-advanced custom logic. And here there’s all kinds of things you could do. You could certainly dynamically adjust your EB setting in response to your AD being hit. You could also have different AD settings based on the
amount by which a block exceeds your EB setting. You could even have different AD settings based on the
identity of the pool that mines a block over your EB setting. But what’s really essential about BU, and what we shouldn’t lose sight of when people are attempting to critique various details of its implementation (that are really just bells and whistles), is that it shatters
“the social illusion that devs are gatekeepers to these parameters.”