[bitcoin-dev] Proposal: Soft Fork Threshold Signaling

Sancho Panza sanch0panza at protonmail.com
Thu Apr 13 16:35:41 UTC 2017

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170413/fd2d178a/attachment.html>

More information about the bitcoin-dev mailing list