📅 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
>
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 18:00:01
in reply to nevent1q…0ss7
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 18:00:01Event JSON
{
"id": "4afaf0005a575a231092d2bd8910cf9badc2f0b71917132ceed86e8db532c9c2",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686160801,
"kind": 1,
"tags": [
[
"e",
"9968011d68a4e70eb0ca70a0a52bf4f84362919269ed1a238ced3ca92e72f502",
"",
"root"
],
[
"e",
"4a3959d41839944c862ebca7fa98f5e0cc50b4a3d79603a099bbd3a18c2a7760",
"",
"reply"
],
[
"p",
"a9caed86d21b3cc6356c289ed2aeb2c219bf1d6b85255c98a935d53b4377ef20"
]
],
"content": "📅 Original date posted:2017-04-13\n📝 Original message:Hi Sancho,\n\nI saw your proposal. However, my point is that the threshold should be\npart of the signaling, and not fixed in the soft-fork proposal.\n\nI agree that coinbase space might be a limitation.\n\nTo avoid this, I realize that the threshold could be encoded in the\nversion bits. We have 32 version bits, and the top 3 bits must be set to\n001 in BIP9. In order to extend BIP9 in a backward compatible way, we\ncould set these 3 top bits to 010, and use the 29 remaining bits for\nsoft fork signaling.\n\nIf we use 7 bits per soft-fork proposal, we have enough space to encode\nfour simultaneous soft-fork proposals, and sub-percent granularity for\nthe threshold (2^7=128).\n\n\n\nLe 13/04/2017 à 16:17, Sancho Panza a écrit :\n\u003e Thomas,\n\u003e \n\u003e I wonder if you've seen my proposal on how to make BIP9 more configurable:\n\u003e https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki\n\u003e \n\u003e This could be extended with a coinbase signaling feature as you suggest.\n\u003e This could include parameter information for forks which a miner is signaling, for coordination.\n\u003e \n\u003e Currently I've not included something like this, but it might make a nice addition.\n\u003e One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments.\n\u003e \n\u003e Regards,\n\u003e Sancho\n\u003e",
"sig": "2141dc337e86e57abdc16040a2ddd2f502c87d6b5b9d55e5032dd52275cff4475ca0dd9c49bea23017c50b00368385d2f9b85f0670e1cfc7652ee5921d9b849b"
}