📅 Original date posted:2017-04-04
📝 Original message:On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:
> ==Specification==
>
> To be elaborated.
Please do elaborate :)
The meat of the proposal is missing.
> It is thought that only cosmetic changes are needed to generalize from
> only soft forks to 'soft or hard forks', and to add the additional
> per-bit parameters 'threshold' and 'windowsize'
I agree that the type of forks are rather irrelevant to the voting
mechanism. As we remember that BIP109 used a voting bit too.
The per-bit (lets call that per-proposal) parameter threshold and windowsize
are a different matter though, based on the next paragraph you wrote;
> The design of the state machine is envisioned to remain unchanged.
The entire point of BIP9 is to allow nodes that do not know about an upgrade
to still have a functional state machine. But I don’t see how you can have a
state machine if the two basic variables that drive it are not specified.
Now, to be clear, I am a big fan of making the window size and the threshold
more flexible.
But in my opinion we would not be able to have a state machine without those
variables in the actual BIP because old nodes would miss the data to
transition to certain states.
Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse
the CSV one). Maybe we can come up with 3 default sets of properties and
when a proposal starts to use bit 11 it behaves differently than if it uses
22.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Tom Zander [ARCHIVE] /
npub1mj…dxnq7
2023-06-07 17:59:01
in reply to nevent1q…r2va
Author Public Key
npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7Published at
2023-06-07 17:59:01Event JSON
{
"id": "495bdd41e5ecb29dcf1f80b2a520e854290f68373b8338eaa634c169e010f510",
"pubkey": "dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7",
"created_at": 1686160741,
"kind": 1,
"tags": [
[
"e",
"3909d155f1982e3a0b455d11e4ee4341d4be262d42cc407a1e3075f6c71d559b",
"",
"root"
],
[
"e",
"417f3715bd199b60595a537213e9880a41ddc34f8a5deb75e296821f2b4297e1",
"",
"reply"
],
[
"p",
"a9caed86d21b3cc6356c289ed2aeb2c219bf1d6b85255c98a935d53b4377ef20"
]
],
"content": "📅 Original date posted:2017-04-04\n📝 Original message:On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:\n\u003e ==Specification==\n\u003e \n\u003e To be elaborated.\n\nPlease do elaborate :)\n\nThe meat of the proposal is missing.\n \n\u003e It is thought that only cosmetic changes are needed to generalize from\n\u003e only soft forks to 'soft or hard forks', and to add the additional\n\u003e per-bit parameters 'threshold' and 'windowsize'\n\nI agree that the type of forks are rather irrelevant to the voting \nmechanism. As we remember that BIP109 used a voting bit too.\n\nThe per-bit (lets call that per-proposal) parameter threshold and windowsize \nare a different matter though, based on the next paragraph you wrote;\n\n\u003e The design of the state machine is envisioned to remain unchanged.\n\nThe entire point of BIP9 is to allow nodes that do not know about an upgrade \nto still have a functional state machine. But I don’t see how you can have a \nstate machine if the two basic variables that drive it are not specified.\n\nNow, to be clear, I am a big fan of making the window size and the threshold \nmore flexible.\nBut in my opinion we would not be able to have a state machine without those \nvariables in the actual BIP because old nodes would miss the data to \ntransition to certain states.\n\nMaybe an idea; we have 30 bits. 2 currently in use (although we could reuse \nthe CSV one). Maybe we can come up with 3 default sets of properties and \nwhen a proposal starts to use bit 11 it behaves differently than if it uses \n22.\n-- \nTom Zander\nBlog: https://zander.github.io\nVlog: https://vimeo.com/channels/tomscryptochannel",
"sig": "580ef7b7e0ce33ab1d4aa19dfde5f14d0ff0b6df60857ebfc6ac3e56b11bf03b38f16b80f3677eecab09991b59b0c632b2e7e73aeca4681680ba90245b407777"
}