Sancho Panza [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-04 📝 Original message:Thanks for the feedback. ...
📅 Original date posted:2017-04-04
📝 Original message:Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is more complete.
For now I think more discussion will be very helpful.
I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes.
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.
What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same.
But the parameters that decide those transitions would be unique per bit.
I think you misunderstood me if you think there will be strictly one singular state machine.
Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently.
An initial implementation might provide this all in compiled code.
A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations.
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.
As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this.
This proposal does not fundamentally change that situation.
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.
One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples.
I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds).
Of course in reality most bits are unused today.
Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured.
Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170404/9f226b05/attachment-0001.html>;
📝 Original message:Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is more complete.
For now I think more discussion will be very helpful.
I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes.
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.
What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same.
But the parameters that decide those transitions would be unique per bit.
I think you misunderstood me if you think there will be strictly one singular state machine.
Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently.
An initial implementation might provide this all in compiled code.
A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations.
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.
As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this.
This proposal does not fundamentally change that situation.
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.
One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples.
I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds).
Of course in reality most bits are unused today.
Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured.
Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170404/9f226b05/attachment-0001.html>;