You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge #6729: feat: prohibit new legacy scheme masternodes, restrict ProTx version changes with DEPLOYMENT_V23
af10784 doc: add release notes for version restrictions (Kittywhiskers Van Gogh)
991f14d evo: prohibit new legacy scheme masternode registrations (Kittywhiskers Van Gogh)
abf96b5 evo: prohibit extended address versioning on unsupported transactions (Kittywhiskers Van Gogh)
de7f928 evo: prohibit upgrading from LegacyBLS to ExtAddr support directly (Kittywhiskers Van Gogh)
e430e6e evo: prohibit any ProTx with legacy BLS version after basic BLS upgrade (Kittywhiskers Van Gogh)
dc687a9 rpc: constrain ProTx version for ProUpRevTx based on legacy status (Kittywhiskers Van Gogh)
23c5152 trivial: use consistent variable name, use brackets (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Depends on #6665
* Depends on #6723
* Please refer to comments from [dash#6665](#6665) for prior discussion on the contents of the pull request ([comment](#6665 (comment)), [comment](#6665 (comment)), [comment](#6665 (comment)))
* Complementing the deprecation in [dash#6723](#6723), after `DEPLOYMENT_V23` is activated
* Registration of **new** masternodes (i.e. `ProRegTx`) with the legacy scheme (`LegacyBLS`) will no longer be allowed. Existing masternodes are not affected and can continue to operate and participate.
* Masternodes that are already using the basic scheme (`BasicBLS`) or higher may no longer **downgrade** to the legacy scheme.
* Additional guardrails have been introduced to complement [dash#6665](#6665), which reserves a new version for extended addresses (`ExtAddr`), affecting `ProRegTx` and `ProUpServTx`, applicable after `DEPLOYMENT_V23` is activated
* Masternodes **must** migrate to the basic scheme (`BasicBLS`) _before_ attempting to utilize extended addresses (`ExtAddr`), legacy scheme nodes may not attempt a direct upgrade.
* Special transactions other than `ProRegTx` or `ProUpServTx` may not bear the version reserved for extended addresses (`ExtAddr`). Note that `IsVersionChangeValid()` does not extend to `ProRegTx` as it _creates_ a new entry and therefore doesn't have a masternode state version to compare against (i.e. there's no version to _change_), so the restriction in `IsVersionChangeValid()` only _de facto_ applies to `ProUpServTx`.
* Future version updates must be conscious of updates to the masternode state ([source](https://github.com/dashpay/dash/blob/d9f52acecb94d57be91b5e17d478d5c909df3633/src/evo/deterministicmns.cpp#L887-L888)), example code for what changes may be required are available [here](#6665 (comment)).
## Breaking Changes
* `protx revoke` will no longer default to using the highest possible version of `ProUpRevTx` and will now _clamp_ the version to `LegacyBLS` if the masternode uses the legacy scheme.
## Checklist
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)**
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
PastaPastaPasta:
utACK af10784
UdjinM6:
utACK af10784
Tree-SHA512: fe788c33397f9e351377777946d5c0498569f68f22d308cce03f903fb3e149bd594ce2caafc50fd62611029563e2841bc42151579b21ba42fdf87cbf7762f716
0 commit comments