📅 Original date posted:2017-04-13
📝 Original message: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
>
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 18:00:02
in reply to nevent1q…yyyq
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 18:00:02Event JSON
{
"id": "e234800ecebc2c76f027309b2b0f5ec9c991f66b6d69ee966bd105e39fc0634c",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686160802,
"kind": 1,
"tags": [
[
"e",
"9968011d68a4e70eb0ca70a0a52bf4f84362919269ed1a238ced3ca92e72f502",
"",
"root"
],
[
"e",
"26e2b3a7e18af79c0d0e1f8f6d951c3e454a64e5cd5569b3869d298aaae7f851",
"",
"reply"
],
[
"p",
"a9caed86d21b3cc6356c289ed2aeb2c219bf1d6b85255c98a935d53b4377ef20"
]
],
"content": "📅 Original date posted:2017-04-13\n📝 Original message:I think it is better not to use the coinbase, because it might collide\nwith other proposals, and because coinbase is not part of the block header.\n\nI agree that a small set of standard threshold may be sufficient; a one\npercent resolution is probably not needed. If we use 4 bits we can\nencode 15 different thresholds + zero (meaning no support). For example\nwe can have all thresholds between 25% and 95% separated by 5%.\n\nUsing 4 bits per soft-fork proposal leaves enough room to fit 7\nsimultaneous proposals in version bits. That should be plenty.\n\n\u003e \n\u003e I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling.\n\u003e \n\u003e 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).\n\u003e \n\u003e It would be very easy to also agree on a set of \"standard\" threshold levels and map those onto e.g. 1 byte.\n\u003e \n\u003e 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.\n\u003e So a BIP9 conformant schedule could be A = 95% / 2016 window,\n\u003e while B = 75%/2016, etc.\n\u003e \n\u003e 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.\n\u003e \n\u003e Regards\n\u003e Sancho\n\u003e",
"sig": "20785306550569babc2dbc9ce1e3f03c8d98b57d25f4bda038d87ce7840fced4815f3fe4fd9db37a8f0aba715c131c13b91f0757b15b678401d4b5240517edd9"
}