Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: auto generation EHF and spork+EHF activation for MN_RR #5597

Merged
merged 10 commits into from
Oct 18, 2023

Conversation

knst
Copy link
Collaborator

@knst knst commented Oct 1, 2023

Implementation EHF mechanism, part 4. Previous changes are:

Issue being fixed or feature implemented

Currently MN_RR is activated automatically by soft-fork activation after v20 is activated.
It is not flexible enough, because platform may not be released by that time yet or in opposite it can be too long to wait.
Also, any signal of EHF requires manual actions from MN owners to sign EHF signal - it is automated here.

What was done?

New spork SPORK_24_MN_RR_READY; new EHF manager that sign EHF signals semi-automatically without manual actions; and send transaction with EHF signal when signal is signed to network.
Updated rpc getblockchaininfo to return information about of EHF activated forks.
Fixed function IsTxSafeForMining in chainlock's handler to skip transactions without inputs (empty vin).

How Has This Been Tested?

Run unit/functional tests. Some tests have been updated due to new way of MN_RR activation: feature_asset_locks.py, feature_mnehf.py, feature_llmq_evo.py and unit test block_reward_reallocation_tests.

Breaking Changes

New way of MN_RR activation.

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

@knst knst marked this pull request as draft October 1, 2023 19:54
@knst knst added this to the 20 milestone Oct 2, 2023
@github-actions
Copy link

github-actions bot commented Oct 3, 2023

This pull request has conflicts, please rebase.

@knst knst force-pushed the mnehf-manager branch 2 times, most recently from efe7520 to 8640df5 Compare October 6, 2023 08:55
@knst knst added RPC Some notable changes to RPC params/behaviour/descriptions Needs Release Notes This PR includes breaking changes for which release notes have not yet been merged. labels Oct 6, 2023
@github-actions
Copy link

github-actions bot commented Oct 6, 2023

This pull request has conflicts, please rebase.

@knst knst marked this pull request as ready for review October 9, 2023 11:06
@knst knst changed the title feat: auto generation EHF feat: auto generation EHF and MN_RR spork+EHF activation Oct 9, 2023
@knst knst changed the title feat: auto generation EHF and MN_RR spork+EHF activation feat: auto generation EHF and spork+EHF activation for MN_RR Oct 9, 2023
@github-actions
Copy link

github-actions bot commented Oct 9, 2023

This pull request has conflicts, please rebase.

Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pls see 2ccf9d1

@knst
Copy link
Collaborator Author

knst commented Oct 9, 2023

@UdjinM6
A.
2ccf9d1#diff-4a04bc0b355c780033960e8c261ee9b6d3c452897e1dcd88a15d272512266c76R1133

self.activate_mn_rr(expected_activation_height=node.getblockcount() + 12 * 3)

but it can take a time until recovered sigs are ready and tx with EHF signal is submitted more than one loop iteration:

       while mn_rr_status == 0:
            time.sleep(1)
            mn_rr_status = get_bip9_details(self.nodes[0], 'mn_rr')['ehf']
            self.nodes[0].generate(1)

So, if sig for EHF signal is delayed more than 1 second and 1 block -> it may be more that 12 * 3 blocks required to activate mn_rr, isn't it?


B.
consensus.vDeployments[Consensus::DEPLOYMENT_MN_RR].nWindowSize = 4032;
When v20 would be released it will take time until v20 would be activated (several weeks, 4-6?). After that after spork activation it would be required to wait 4-6 weeks more. Is it expected to wait 4-6 weeks more?

@UdjinM6
Copy link

UdjinM6 commented Oct 10, 2023

@UdjinM6 A. 2ccf9d1#diff-4a04bc0b355c780033960e8c261ee9b6d3c452897e1dcd88a15d272512266c76R1133

self.activate_mn_rr(expected_activation_height=node.getblockcount() + 12 * 3)

but it can take a time until recovered sigs are ready and tx with EHF signal is submitted more than one loop iteration:

       while mn_rr_status == 0:
            time.sleep(1)
            mn_rr_status = get_bip9_details(self.nodes[0], 'mn_rr')['ehf']
            self.nodes[0].generate(1)

So, if sig for EHF signal is delayed more than 1 second and 1 block -> it may be more that 12 * 3 blocks required to activate mn_rr, isn't it?

bip9 works in periods. Also, in this specific case we start activating at the beginning of the period (block 2796) and we have threshold which is lower than that so missing a couple of blocks is not a problem. But I agree that calculating it like that is probably misleading. We could simply go with a static number instead I guess i.e. expected_activation_height=2832.

B. consensus.vDeployments[Consensus::DEPLOYMENT_MN_RR].nWindowSize = 4032; When v20 would be released it will take time until v20 would be activated (several weeks, 4-6?). After that after spork activation it would be required to wait 4-6 weeks more. Is it expected to wait 4-6 weeks more?

Good point 👍 Pls ignore this part of my suggestions then :)

UdjinM6
UdjinM6 previously approved these changes Oct 17, 2023
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-utACK

UdjinM6
UdjinM6 previously approved these changes Oct 17, 2023
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, utACK

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

light-ACK for squash merge

@github-actions
Copy link

This pull request has conflicts, please rebase.

knst and others added 10 commits October 18, 2023 03:56
…Mempool

This commit adds basic implementation for auto-generation of EHF signals.
This implementation is a basement for various EHF (include MN_RR).

Please, notice that some unit and functional tests are broken after this commit
due to unexpected activation of MN_RR (or in opposited expected non-activation)

Next commit is adding a new Spork SPORK_24_MN_RR_READY and fixes all Unit and
Functional tests accordingly new logic of MN_RR activation
This spork is used to signalize EhfSignalsManager that EHF signal
for fork MN_RR can be signed and send to network now (platform is ready)
@knst
Copy link
Collaborator Author

knst commented Oct 17, 2023

@knst knst force-pushed the mnehf-manager branch from b6b165f to 7e96c96

due to

This pull request has conflicts, please rebase.

Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-utACK

@PastaPastaPasta PastaPastaPasta merged commit 63ed462 into dashpay:develop Oct 18, 2023
10 of 11 checks passed
PastaPastaPasta pushed a commit that referenced this pull request Oct 20, 2023
## Issue being fixed or feature implemented
#5597 follow-up 

## What was done?
add missing filed description

## How Has This Been Tested?
`help getblockchaininfo`

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] 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)_
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Release Notes This PR includes breaking changes for which release notes have not yet been merged. RPC Some notable changes to RPC params/behaviour/descriptions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants