I think it is better not to use the coinbase, because it might collide with other proposals, and because coinbase is not part of the block header.
I agree that a small set of standard threshold may be sufficient; a one percent resolution is probably not needed. If we use 4 bits we can encode 15 different thresholds + zero (meaning no support). For example we can have all thresholds between 25% and 95% separated by 5%. Using 4 bits per soft-fork proposal leaves enough room to fit 7 simultaneous proposals in version bits. That should be plenty. > > 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
