> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
