Hi Sancho, I saw your proposal. However, my point is that the threshold should be part of the signaling, and not fixed in the soft-fork proposal.
I agree that coinbase space might be a limitation. To avoid this, I realize that the threshold could be encoded in the version bits. We have 32 version bits, and the top 3 bits must be set to 001 in BIP9. In order to extend BIP9 in a backward compatible way, we could set these 3 top bits to 010, and use the 29 remaining bits for soft fork signaling. If we use 7 bits per soft-fork proposal, we have enough space to encode four simultaneous soft-fork proposals, and sub-percent granularity for the threshold (2^7=128). Le 13/04/2017 à 16:17, Sancho Panza a écrit : > Thomas, > > I wonder if you've seen my proposal on how to make BIP9 more configurable: > https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki > > This could be extended with a coinbase signaling feature as you suggest. > This could include parameter information for forks which a miner is > signaling, for coordination. > > Currently I've not included something like this, but it might make a nice > addition. > One problem is the limited space in coinbase for embedding data on the large > number of possible independent deployments. > > Regards, > Sancho > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev