Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-13 📝 Original message:Hi Sancho, I saw your ...

📅 Original date posted:2017-04-13
📝 Original message: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
>