-
Notifications
You must be signed in to change notification settings - Fork 1.2k
fix: new fork 'withdrawals' and fixes for asset unlock signature verification #6279
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
Conversation
7b33395 to
1870106
Compare
src/chainparams.cpp
Outdated
| consensus.vDeployments[Consensus::DEPLOYMENT_WITHDRAWALS].nStartTime = 1704067200; // January 1, 2024 | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_WITHDRAWALS].nTimeout = 1767225600; // January 1, 2026 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Start time and timeout values for each network should be updated to something more relevant before merging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nStartTimeshould be somewhere in the (near) futurenStartTimeandnTimeoutshould be 1 year apart on mainnet
|
This pull request has conflicts, please rebase. |
|
Needs rebase? |
it depends on #6275 (bury mn_rr) also, which is not merged yet; will rebase after |
b5237f3 to
4a473a1
Compare
|
This pull request has conflicts, please rebase. |
4a473a1 to
7bc3698
Compare
src/chainparams.cpp
Outdated
| consensus.vDeployments[Consensus::DEPLOYMENT_WITHDRAWALS].nStartTime = 1704067200; // January 1, 2024 | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_WITHDRAWALS].nTimeout = 1767225600; // January 1, 2026 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nStartTimeshould be somewhere in the (near) futurenStartTimeandnTimeoutshould be 1 year apart on mainnet
src/evo/assetlocktx.cpp
Outdated
| assert(llmq_params_opt.has_value()); | ||
|
|
||
| // after deployment WITHDRAWALS activated we check not to quorum, but all active quorums + 1 the latest inactive | ||
| const int quorums_to_scan = DeploymentActiveAt(*pindexTip, Params().GetConsensus(), Consensus::DEPLOYMENT_WITHDRAWALS) ? (llmq_params_opt->signingActiveQuorumCount + 1) : 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could use keepOldConnections here
| const int quorums_to_scan = DeploymentActiveAt(*pindexTip, Params().GetConsensus(), Consensus::DEPLOYMENT_WITHDRAWALS) ? (llmq_params_opt->signingActiveQuorumCount + 1) : 2; | |
| const int quorums_to_scan = DeploymentActiveAt(*pindexTip, Params().GetConsensus(), Consensus::DEPLOYMENT_WITHDRAWALS) ? llmq_params_opt->keepOldConnections : 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could use keepOldConnections here
technically, yes
But logically I can't explain myself how signingActiveQuorumCount and keepOldConnections are related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Used for intra-quorum communication. This is the number of quorums for which we should keep old connections.
// For non-rotated quorums it should be at least one more than the active quorums set.
// For rotated quorums it should be equal to 2 x active quorums set.
int keepOldConnections;
https://github.com/dashpay/dash/blob/develop/src/llmq/params.h#L102-L105
i.e. active set + 1 quorum that became inactive recently, exactly what you need here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still says, that in some particular cases it is matched with "+1" indeed, but I can't justify use "keep old connections" as amount of quorums which makes signature valid; also "2x active quorums" for rotating is not relevant for this situation.
|
tests failed |
7bc3698 to
5fd7b07
Compare
fixed test, activation date and rebased to the newer commit - base commit was pretty old |
UdjinM6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@UdjinM6 no, accordingly DIP and by design, |
UdjinM6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pls see 0c8b377
UdjinM6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
invalid syntax in while attempts < 10 (missing:), also pls see below
fea8821 to
d690309
Compare
UdjinM6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK d690309
| return state.Invalid(TxValidationResult::TX_CONSENSUS, "bad-assetunlock-not-active-quorum"); | ||
| return state.Invalid(TxValidationResult::TX_CONSENSUS, "bad-assetunlock-too-old-quorum"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because (active quorums + the latest inactive) are matched. So, quorum can be not-active, but still valid.
? (llmq_params_opt->signingActiveQuorumCount + 1)
PastaPastaPasta
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK d690309
Issue being fixed or feature implemented
https://github.com/dashpay/dash-issues/issues/83
What was done?
Introduces new fork "withdrawals" which let Asset Unlock be valid for any active quorum + 1 extra inactive (in opposite of hard-coded 2 of them).
How Has This Been Tested?
See new test section
test_withdrawals_forkin functional test feature_asset_locks.pyBreaking Changes
Checklist: