> 1. Allow users to signal readiness by publishing an EB. This EB is an absolute upper bound, and cannot be overridden by miners. Current EB is 1MB, the status-quo.   Maybe EB can be configured in a config file, not a UI, since it's an "advanced" feature.
>
> What does EB stand for?

> What is the point of users publishing an EB? Is it for miners to determine what to set theirs to? If so, what about sybil attacks with fake nodes publishing EBs?

You can't trivially fake coinbase's full node, or gemini's, etc.   Large users would also be encouraged to report their EB's publically as well.

> How do users publish an EB? Do they use a transaction? Or is it something that goes into the User Agent?

Same way a version string is published by a node.   Maybe *in* the version string.

> How high can the EB go? What is its maximum?

Maybe 4MB for now?   Seems fine.   Trivial to change it later, since it's not a fork to do so.

> 6. Core can (optionally) ship a version with a default EB in-line with their own perceived consensus. 

I would say that Core /should/ ship new versions with new default EB's in-line with both miner and the economic majority after a 95% consensus fork.

> 7. Some sort of versioning system is used to ensure that the two networks (old and new) are incompatible... blocks hashed in one cannot be used in the other.
>
> I think this would require a soft fork beforehand in order to implement such a system.

I thought versionbits could handle this?   Can't they?  ALP pointed out that it was important for a fork to be fully incompatible.

> It would be in the best interests of major exchanges and users would to publicly announce their EB's.
>
> Why?

So miners can have a more reliable signal to go on.   No reasonable miner would start mining signal for a fork unless they were confident that they are doing so in-line with users and exchanges.

> "Scaling" includes a lot more than just the block size. There is much more to scaling than just increasing the block size.

Yes, which is why I used air-quotes.   The primary idea is to remove a political issue from affecting core developers.   There is a perception among some people that "if only core would....".   Plus, fees are *inherently* political because it is a barrier for low-net-worth individuals transacting using this technology.   Even if lightning worked perfectly, how can a small business in Africa afford to set up a full node and being to participate as a hub if fees are $50?   OMG blame core. 

Miners and users should be free to wrangle each other over fees any time they want without the involvement of developers.   I suspect the status quo would be even *more* stable in that scenario... not less.

> What if the EB of a new node is set to be smaller than the current block size?

Then it is only used for signal unless a fork occurs that results in a reduction <= EB... in which case the EB becomes a hard upper bound, just like any other.   When an EB is set by a user a block-height needs to be recorded along with it, so it can be handled correctly.   EB set to < active seems to me to be a special case.   Likewise the percentile shoudl be the upper 5% in the case of EB < active.   

This essentially partitions signalling into "< active" and "> active".