Are you speaking for yourself as a node operator, or are you trying to look out for miners? I don't understand why operators of non-mining nodes would be overly concerned with coordination.
I'm speaking about my preferences as a regular node operator. Chain splits that I didn't know about should be rare enough that I don't want my node to automatically do anything without my input in that case. If there has been a chain split, I want my node to ask me "Yo, a longer chain with larger blocks exists than your current settings are configured to accept exists. Want to switch to that chain? Y/N." I can then do any investigation I need to do regarding the fork.
(An ideal wallet would actually track both chains if they continued to exist and let me separately manage my coins on each, but that's much more complex.)
The way I see it, if I'm wearing my "node operator hat," the most important tools to me are (1) EB and (2) AD -- I hardly care about coordination because I'm probably running with an EB greater than the miners anyways, and if not, then my AD will ensure I don't fork.
I believe avoiding the 'scenario #1' and 'scenario #3' that I outlined in my original post are worth not wanting to use an EB greater than the current consensus max block size and not use AD at all, respectively.
@Roger_Murdock replied casting doubt on the likelihood of those scenarios and I didn't dive into details with him, but I'll now explain why I think he underestimates the risks (even though they're still small):
First, it's claimed that only one > 1 MB block has ever been mined, so it's so rare as to not be worth worrying about. The reason that this is the case is that throughout Bitcoin's history, most people haven't been using EC. If the entire network migrated to EC, then situations where a new block was mined that is larger than all previous blocks in the chain would be more common.
Second, Roger assumes that any > 1 MB block would be mined accidentally, but it may be a deliberate attack, especially if lots of people use EB > current max block size. The attack is profitable if you can trick some portion of ~2000 people (or ~4000, or more depending on the block size) into sending you value whose sum across all people is greater than the expected normal block reward. As a miner you can try to trick one person for every transaction that you can include in the block. If blocks were 4 MB, then attackers could try to trick 8,000 people and would only need to extract $2.50 of value from each one.
Maybe this attack wouldn't actually be profitable, but running EB > the current max block size doesn't give enough benefit that it seems worth it. If these attacks occasionally happened, then even if I'm not a target of the attack, 1-confirmation transactions suddenly become less meaningful to me just because of the settings I happen to be running. If I change EB = the current max block size, then I can be a little more confident about 1-confirmation transactions. Not a huge deal, but again the benefit of setting EB > the max block size is also minuscule because (a) I will have heard about any fork, (b) if I hadn't, I much prefer if the software just warns me so I can manually make a choice.
Also, if I was so nonchalant about whether confirmed transactions were valid that you think I should ignore this, why was I running a full node in the first place? The "oh, that's unlikely, don't worry about it" argument applies to anyone who wants to run a full node instead of SPV, since SPV security is actually quite good.
For 'scenario 3' where a hash rate majority starts producing blocks above my EB, it doesn't need to be an especially malicious group of miners resulting in Bitcoin's security model completely breaking. I bet if Jihan and his mining friends got 65% of hash power and decided to unilaterally hard fork to 32 MB blocks, most people in this forum would go along with it and not see it as an "attack" that break's Bitcoin's security model. In this case, I don't want my software to just assume I want to follow the 32 MB chain. Maybe I will end up following it, but what I really want to do is follow the chain that the economic majority will follow. Perhaps after investigating the fork a bit, I decide that I think Jihan was a bit too aggressive with the 32 MB thing, and I think the economic majority will go against his chain. This kind of contentious chain split where both sides have sincere believers is a real possibility, and I definitely prefer making a manual choice in this case.
As discussed previously, if there was such a contentious split the AD setting wouldn't actually harm me much because it's likely that I would have been paying attention, but that just means that AD would be unnecessary. If I am paying attention, I don't need AD. If I'm not paying attention for some strange reason, then I definitely want to be prompted to make a manual choice and not have my software silently follow the hash rate majority no matter what.
I think part of what causes people on this forum to not see problems with AD is the belief that you actually do want to follow the hash rate majority almost no matter what.
Yeah, I'd prefer using EB for both too. I think it would be easy to infer the context as you point out. In fact, I started out using "EB" for both but then people told me that it was confusing and that I should use "FE." C'est la vie.
Cool, I feel pretty strongly that "FE", "FG" (whatever that is) are messier and add unnecessary complexity. If EB@500000 means "the EB setting at block 500000 or later", then coming up with a new parameter name seems pointless. Can someone who thinks "FE" and "FG" are somehow useful terms please explain why?
