> However, my point is that the threshold should be [...]  not fixed in the soft-fork proposal

My proposal makes it configurable (as well as window size, grace period etc.)

> I agree that coinbase space might be a limitation.

I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling.

BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments).

It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte.

Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful.

So a BIP9 conformant schedule could be A = 95% / 2016 window,

while B = 75%/2016, etc.

This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention.

Regards

Sancho