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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
