## Issue being fixed or feature implemented
we should not vote on triggers from the past
## What was done?
## How Has This Been Tested?
n/a
## 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)_
## Issue being fixed or feature implemented
Asset Unlock tx uses platform's quorum on devnets, testnet, mainnet, but
still quorum type "Test (100)" on Reg Tests
That's part II PR, prior work is here:
https://github.com/dashpay/dash/pull/5618
## What was done?
- Removed `consensus.llmqTypeAssetLocks` which has been kept only for
RegTest - use `consensus.llmqTypePlatform` instead.
- Functional test `feature_asset_locks.py` uses `llmq_type_test = 106`
instead `llmq_type_test = 100` for asset unlock tx
- there's 4 MNs + 3 evo nodes instead 3 MNs as before: evo nodes
requires to have IS to be active
## How Has This Been Tested?
Run unit/functional tests
## Breaking Changes
Asset Unlock tx uses correct quorum "106 llmq_test_platform" on reg test
instead "100 llmq_test"
## 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
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
Cache population for old quorums is a cpu heavy operation and should be
avoided for inactive quorums _at least_ oin `ScanQuorums`. This issue is
critical for testnet and other small network because every mn
participate in almost every platform quorum and cache population for 2
months of quorums can easily block everything for 15+ minutes on a 4 cpu
node. On mainnet quorum distribution is much better but it's still a
small waste of cpu (or not so small for unlucky nodes).
#5761 follow-up
## What was done?
Do not start cache population for outdated quorums, improve logs in
`StartCachePopulatorThread` to make it easier to see what's going on.
## How Has This Been Tested?
run a mn on testnet
## 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)_
## Issue being fixed or feature implemented
`instantlock` and `chainlock` are broken in `getspecialtxes`
kudos to @thephez for finding the issue
## What was done?
pass the hash and also rename the variable to self-describing
## How Has This Been Tested?
run `getspecialtxes` on a node with and without the patch
## Breaking Changes
`instantlock` and `chainlock` will show actual values and not just
`false` all the time now (not sure if that qualifies for "breaking"
though)
## 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)_
## Issue being fixed or feature implemented
1. `scanQuorumsCache` is a special one and we use it incorrectly.
2. Platform doesn't really use anything that calls `ScanQuorums()`
directly, they specify the exact quorum hash in RPCs so it's
`GetQuorum()` that is used instead. The only place `ScanQuorums()` is
used for Platform related stuff is `StartCleanupOldQuorumDataThread()`
because we want to preserve quorum data used by `GetQuorum()`. But this
can be optimised with its own (much more compact) cache.
3. RPCs that use `ScanQuorums()` should in most cases be ok with smaller
cache, for other use cases there is a note in help text now.
## What was done?
pls see individual commits
## How Has This Been Tested?
run tests, run a node (~in progress~ looks stable)
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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
## Issue being fixed or feature implemented
Now that we have ChainLock sigs in coinbase `VerifyDB()` have to process
them. It works most of the time because usually we simply read
contributions from quorum db
https://github.com/dashpay/dash/blob/develop/src/llmq/quorums.cpp#L385.
However, sometimes these contributions aren't available so we try to
re-build them
https://github.com/dashpay/dash/blob/develop/src/llmq/quorums.cpp#L388.
But by the time we call `VerifyDB()` bls worker threads aren't started
yet, so we keep pushing jobs into worker's queue but it can't do
anything and it halts everything.
backtrace:
```
* frame #0: 0x00007fdd85a2873d libc.so.6`syscall at syscall.S:38
frame #1: 0x0000555c41152921 dashd_testnet`std::__atomic_futex_unsigned_base::_M_futex_wait_until(unsigned int*, unsigned int, bool, std::chrono::duration<long, std::ratio<1l, 1l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> >) + 225
frame #2: 0x0000555c40e22bd2 dashd_testnet`CBLSWorker::BuildQuorumVerificationVector(Span<std::shared_ptr<std::vector<CBLSPublicKey, std::allocator<CBLSPublicKey> > > >, bool) at atomic_futex.h:102:36
frame #3: 0x0000555c40d35567 dashd_testnet`llmq::CQuorumManager::BuildQuorumContributions(std::unique_ptr<llmq::CFinalCommitment, std::default_delete<llmq::CFinalCommitment> > const&, std::shared_ptr<llmq::CQuorum> const&) const at quorums.cpp:419:65
frame #4: 0x0000555c40d3b9d1 dashd_testnet`llmq::CQuorumManager::BuildQuorumFromCommitment(Consensus::LLMQType, gsl::not_null<CBlockIndex const*>) const at quorums.cpp:388:37
frame #5: 0x0000555c40d3c415 dashd_testnet`llmq::CQuorumManager::GetQuorum(Consensus::LLMQType, gsl::not_null<CBlockIndex const*>) const at quorums.cpp:588:37
frame #6: 0x0000555c40d406a9 dashd_testnet`llmq::CQuorumManager::ScanQuorums(Consensus::LLMQType, CBlockIndex const*, unsigned long) const at quorums.cpp:545:64
frame #7: 0x0000555c40937629 dashd_testnet`llmq::CSigningManager::SelectQuorumForSigning(Consensus::LLMQParams const&, llmq::CQuorumManager const&, uint256 const&, int, int) at signing.cpp:1038:90
frame #8: 0x0000555c40937d34 dashd_testnet`llmq::CSigningManager::VerifyRecoveredSig(Consensus::LLMQType, llmq::CQuorumManager const&, int, uint256 const&, uint256 const&, CBLSSignature const&, int) at signing.cpp:1061:113
frame #9: 0x0000555c408e2d43 dashd_testnet`llmq::CChainLocksHandler::VerifyChainLock(llmq::CChainLockSig const&) const at chainlocks.cpp:559:53
frame #10: 0x0000555c40c8b09e dashd_testnet`CheckCbTxBestChainlock(CBlock const&, CBlockIndex const*, llmq::CChainLocksHandler const&, BlockValidationState&) at cbtx.cpp:368:47
frame #11: 0x0000555c40cf75db dashd_testnet`ProcessSpecialTxsInBlock(CBlock const&, CBlockIndex const*, CMNHFManager&, llmq::CQuorumBlockProcessor&, llmq::CChainLocksHandler const&, Consensus::Params const&, CCoinsViewCache const&, bool, bool, BlockValidationState&, std::optional<MNListUpdates>&) at specialtxman.cpp:202:60
frame #12: 0x0000555c40c00a47 dashd_testnet`CChainState::ConnectBlock(CBlock const&, BlockValidationState&, CBlockIndex*, CCoinsViewCache&, bool) at validation.cpp:2179:34
frame #13: 0x0000555c40c0e593 dashd_testnet`CVerifyDB::VerifyDB(CChainState&, CChainParams const&, CCoinsView&, CEvoDB&, int, int) at validation.cpp:4789:41
frame #14: 0x0000555c40851627 dashd_testnet`AppInitMain(std::variant<std::nullopt_t, std::reference_wrapper<NodeContext>, std::reference_wrapper<WalletContext>, std::reference_wrapper<CTxMemPool>, std::reference_wrapper<ChainstateManager>, std::reference_wrapper<CBlockPolicyEstimator>, std::reference_wrapper<LLMQContext> > const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*) at init.cpp:2098:50
frame #15: 0x0000555c4082fe11 dashd_testnet`AppInit(int, char**) at bitcoind.cpp:145:54
frame #16: 0x0000555c40823c64 dashd_testnet`main at bitcoind.cpp:173:20
frame #17: 0x00007fdd85934083 libc.so.6`__libc_start_main(main=(dashd_testnet`main at bitcoind.cpp:160:1), argc=3, argv=0x00007ffcb8ca5b88, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007ffcb8ca5b78) at libc-start.c:308:16
frame #18: 0x0000555c4082f27e dashd_testnet`_start + 46
```
Fixes#5741
## What was done?
Start LLMQContext early. Alternative solution could be moving bls worker
Start/Stop into llmq context ctor/dtor.
## How Has This Been Tested?
I had a node with that issue. This patch fixed it.
## Breaking Changes
Not sure, hopefully none.
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
## Issue being fixed or feature implemented
Missing changes in https://github.com/dashpay/dash/pull/5736
The prior backport of https://github.com/bitcoin/bitcoin/pull/19438 has
been needed to this particular changes: drop the mutex `cs_llmq_vbc`.
This mutex can potentially cause deadlock such as:
```
'cs_dip3list' in qt/masternodelist.cpp:135 (TRY) (in thread 'main')
(2) 'cs_llmq_vbc' in llmq/utils.cpp:704 (in thread 'main')
'm_mutex' in versionbits.cpp:253 (in thread 'main')
(1) 'cs_main' in node/blockstorage.cpp:77 (in thread 'main')
Current lock order is:
'cs_Shutdown' in init.cpp:220 (TRY) (in thread 'shutoff')
(1) 'cs_main' in init.cpp:328 (in thread 'shutoff')
(2) 'llmq::cs_llmq_vbc' in llmq/context.cpp:64 (in thread 'shutoff')
Assertion failed: detected inconsistent lock order for 'llmq::cs_llmq_vbc' in llmq/context.cpp:64 (in thread 'shutoff'), details in debug log.
```
## What was done?
Drop `cs_llmq_vbc` mutex from llmq/utils
## How Has This Been Tested?
Re-started app several times -> no other deadlock happens.
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
## Issue being fixed or feature implemented
Fixes a bug we missed in #5736
## What was done?
Use all collected indexes, not just the last one
## How Has This Been Tested?
## 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)_
Prior required changes: bitcoin/bitcoin#19438 from
https://github.com/dashpay/dash/pull/5740
## Issue being fixed or feature implemented
Assertion failure:
```
assertion: ok
file: evo/mnhftx.cpp, line: 287
function: AbstractEHFManager::Signals CMNHFManager::GetFromCache(const CBlockIndex*)
No debug information available for stacktrace. You should add debug information and then run: dash-qt -printcrashinfo=bvcgc43iinzgc43ijfxgm3ybaadwiyltnawxc5e3ifzxgzlsoruw63ramzqws3dvojstucraebqxg43foj2gs33ohiqg62ykeaqgm2lmmu5cazlwn4xw23timz2hqltdobycyidmnfxgkoragi4docraebthk3tdoruw63r2ebawe43uojqwg5cfjbde2ylomftwk4r2hjjwsz3omfwhgicdjvheqrsnmfxgcz3foi5dur3fordhe33ninqwg2dffbrw63ttoqqegqtmn5rwwslomrsxqkrjbyrelhyaaaaaaaedgkiaaaaaaaadsm4qaaaaaaaa7gpyqaaaaaaaa2njraaaaaaaadkl3caaaaaaaabhxznqaaaaaaadqa2eaaaaaaaax33twaaaaaaabwaihqaaaaaaac7yooqbaaaaaahba45qcaaaaaacwkz2aeaaaaaaeitgeaiaaaaaaaa=
dash-qt: evo/mnhftx.cpp:287: AbstractEHFManager::Signals CMNHFManager::GetFromCache(const CBlockIndex*): Assertion `ok' failed.
```
This can happen in case if Dash Core has been update from v19 (or
earlier v20.alphaX) to v20.0.0 after v20 activation without re-indexing
## What was done?
`CMNHFManager` is visiting missing blocks recursively until reach first
v20 block or first block actually saved in evoDb.
Without changes from bitcoin/bitcoin#19438 there's an other issue:
```
2023-11-27T11:12:10Z POTENTIAL DEADLOCK DETECTED
Previous lock order was:
(2) 'cs_main' in llmq/instantsend.cpp:459 (in thread 'isman')
(1) 'cs_llmq_vbc' in llmq/utils.cpp:711 (in thread 'isman')
Current lock order is:
'cs_dip3list' in qt/masternodelist.cpp:135 (TRY) (in thread 'main')
(1) 'cs_llmq_vbc' in llmq/utils.cpp:719 (in thread 'main')
(2) 'cs_main' in node/blockstorage.cpp:77 (in thread 'main')
Assertion failed: detected inconsistent lock order for 'cs_main' in node/blockstorage.cpp:77 (in thread 'main'), details in debug log.
2023-11-27T11:12:10Z Posix Signal: Aborted
```
## How Has This Been Tested?
Run unit/functional test; run dash-qt on my local backup of problematic
storage (succeed without error); reindex testnet.
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
## Issue being fixed or feature implemented
When DKG data recovery is triggered by `qgetdata` the data we use to
construct `qdata` reply is actually the one handled by
`CDKGSessionManager`, not by `CQuorumManager`. Not storing the data long
enough in `CDKGSessionManager` will result in this data simply not being
recoverable.
Also, the formula in `CDKGSessionManager::CleanupOldContributions()` is
broken for quorums which use rotation (the depth is way too large).
## What was done?
Fix both issues by redefining `keepOldKeys` and aligning key storage
depths in both modules.
## How Has This Been Tested?
## 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)_
## Issue being fixed or feature implemented
Avoid a crash on -reindex-chainstate.
## What was done?
`ResetBlockFailureFlags` is crashing when `m_chain.Tip()` is null. Call
`ResetBlockFailureFlags` inside `if (!is_coinsview_empty(chainstate))
{...}` block - we know `m_chain.Tip()` is not null there.
## How Has This Been Tested?
Try running a node with `-reindex-chainstate` cmd-line param w/ and
w/out this patch.
## 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)_
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/pull/4788#discussion_r854468664
noticed while working on #5731
## What was done?
## How Has This Been Tested?
run a node, check logs - there is a meaningful time span between `start`
and `done` now and not just zeros all the time.
## Breaking Changes
## 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)_
## Issue being fixed or feature implemented
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
---------
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
## Issue being fixed or feature implemented
Should fix compilation errors like
```
masternode/meta.cpp:43:9: error: call to member function 'pushKV' is ambiguous
ret.pushKV("lastOutboundAttemptElapsed", now - lastOutboundAttempt);
^~
masternode/meta.cpp:45:9: error: call to member function 'pushKV' is ambiguous
ret.pushKV("lastOutboundSuccessElapsed", now - lastOutboundSuccess);
^~
```
on FreeBSD + clang-15
kudos to @MrDefacto for finding the issue and testing the fix
## What was done?
Specify `now` variable type explicitly instead of relying on `auto`
## How Has This Been Tested?
MrDefacto confirmed it compiles with no issues on FreeBSD now
## 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)_
## Issue being fixed or feature implemented
Should fix crashes like
```
: Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
Assertion failure:
assertion: globalInstance == nullptr
file: mnhftx.cpp, line: 43
function: CMNHFManager
0#: (0x105ADA27C) stacktraces.cpp:629 - __assert_rtn
1#: (0x104945794) mnhftx.cpp:43 - CMNHFManager::CMNHFManager(CEvoDB&)
2#: (0x10499DA90) compressed_pair.h:40 - std::__1::__unique_if<CMNHFManager>::__unique_single std::__1::make_unique[abi:v15006]<CMNHFManager, CEvoDB&>(CEvoDB&)
3#: (0x10499753C) init.cpp:1915 - AppInitMain(std::__1::variant<std::__1::nullopt_t, std::__1::reference_wrapper<NodeContext>, std::__1::reference_wrapper<WalletContext>, std::__1::reference_wrapper<CTxMemPool>, std::__1::reference_wrapper<ChainstateManager>, std::__1::reference_wrapper<CBlockPolicyEstimator>, std::__1::reference_wrapper<LLMQContext>> const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*)
```
## What was done?
## How Has This Been Tested?
## 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)_
## Issue being fixed or feature implemented
`ConnectBlock` can fail after `ProcessSpecialTxsInBlock`, we shouldn't
be notifying too early. Same for `DisconnectBlock` but that's less of an
issue imo.
## What was done?
Move notifications to the end of `ConnectBlock`/`DisconnectBlock`. There
is no `connman` in `CChainState` and I don't want to pass it in updates
struct so I changed `NotifyMasternodeListChanged` and used `connman`
from `CDSNotificationInterface` instead.
## How Has This Been Tested?
run unit test, run testnet qt wallet
## Breaking Changes
## 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)_
## Issue being fixed or feature implemented
`creditpool` and `ehf` categories are missing in `logging`/`debug` RPCs
😞
## What was done?
## How Has This Been Tested?
run `debug` and `logging` RPCs and make sure these categories are listed
now
## 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)_
## Issue being fixed or feature implemented
mn_rr should be backwards compatible to v20.0.0; in the case we need to
introduce breaking changes on any of the features in mn_rr then we
should create a new mn_rr_v2 hard fork.
## What was done?
Add timestamps for mn_rr for main net activation
## How Has This Been Tested?
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [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)_
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
## Issue being fixed or feature implemented
Be more explicit about the fact that spork24 is for non-mainnet only,
enforce it in code.
NOTE: I know we have EHF signalling disabled for mainnet in v20 but I
think it still makes sense to make sure spork24 condition won't slip
into mainnet in some future version accidentally.
## What was done?
pls see individual commits
## How Has This Been Tested?
## 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)_
## Issue being fixed or feature implemented
1. we _should not_ skip masternode payments checks below
nSuperblockStartBlock or when governance is disabled
2. we _should_ skip superblock payee checks while we aren't synced yet
(should help recovering from missed triggers)
## What was done?
pls see individual commits.
## How Has This Been Tested?
run tests, sync w/ and w/out `--disablegovernance`, reindexed on testnet
## 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)_
## Issue being fixed or feature implemented
When Platform restarts on a network, it needs to sign requests using old
quorums.
We shouldn't remove data (secret key shares, vvec) for old Platform
quorums as we do with the rest of the llmqs.
## What was done?
We skip removing for Platform quorums younger than 2 months.
## How Has This Been Tested?
## Breaking Changes
no
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
## Issue being fixed or feature implemented
```
Assertion failure:
assertion: quorum != nullptr
file: quorums.cpp, line: 547
function: ScanQuorums
```
## What was done?
Hold cs_main while scanning to make sure tip doesn't move. Happened in
`ProcessPendingInstantSendLocks()` only for me but I thought that it
would probably make sense to apply the same fix in other places too.
## How Has This Been Tested?
run `invalidateblock` for a deep enough height (100s of blocks)
## 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)_
## Issue being fixed or feature implemented
Use not_null if the function would crash if given a nullptr
## What was done?
Refactored to use gsl::not_null
## How Has This Been Tested?
Compiled
## Breaking Changes
Should be none
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [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)_
## Issue being fixed or feature implemented
Addressed issues and comments from [PR
comment](https://github.com/dashpay/dash/pull/5469#discussion_r1317886678)
and [PR
comment](https://github.com/dashpay/dash/pull/5469#discussion_r1338704082)
`Params()` should be const; global variable `CMNHFManager` is a better
out-come.
## What was done?
The helpers and direct calls of `UpdateMNParams` for each block to
update non-constant member in `Params()` is not needed anymore. Instead
`CMNHFManager` takes cares about status of Signals for each block,
update them dynamically and save in evo db.
## How Has This Been Tested?
Run unit/functional tests.
## Breaking Changes
Changed rpc `getblockchaininfo`.
the field `ehf` changed meaning: it's now only a flag -1/0; but it is
introduced a new field `ehf_height` now that a height.
## 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
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
---------
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
Co-authored-by: thephez <thephez@users.noreply.github.com>
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/issues/5471
## What was done?
It splits from https://github.com/dashpay/dash/pull/5443
Adds extra unit tests for BLS basic scheme; enforces BLS basic for Evo
Nodes in serialization/unserialization of CProRegTx, CProUpServTx.
## How Has This Been Tested?
Run functional/unit tests + added new unit tests.
## Breaking Changes
Serialization slightly changed, but it should be not breaking change
## 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
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
## Issue being fixed or feature implemented
Currently, on functional tests v20 activates at height 1440 which is
later than needed.
## What was done?
Reduced the window size of v20 from 480 to 400 which activates v20 at
1200.
Adjusted tests to this change.
Note regarding the window analysis for MN payments in
`feature_llmq_evo.py` (reduced from 256 to 48 blocks):
48 window is enough to analyse 4 MNs and 5 EvoNodes (Weighted count=24)
On my machine using develop:
`python3 feature_llmq_rotation.py 145.45s user 30.00s system 68% cpu
4:16.93 total`
With this PR:
`python3 feature_llmq_rotation.py 119.26s user 24.61s system 62% cpu
3:50.89 total`
## How Has This Been Tested?
all tests
## Breaking Changes
no
## 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)_
63631beef6a0046390469971adf4500718ab34ad test: Remove intermittently failing and not very meaningful `BOOST_CHECK` in `cnetaddr_basic` (practicalswift)
Pull request description:
Remove intermittently failing and not very meaningful `BOOST_CHECK` in `cnetaddr_basic`.
Fixes#21682.
Rationale from https://github.com/bitcoin/bitcoin/issues/21682#issuecomment-819897122:
> I've looked at that test before and I don't think that specific `BOOST_CHECK` makes much sense TBH :)
>
> 1.) I don't understand why we test if `ToString()` output includes `%zone_index`: it clearly doesn't on some platforms, so we cannot rely on it anyways. Then why test it?
>
> 2.) And perhaps more fundamentally: why would we even _want_ to have `%zone_index` in our textual `ToString()` output? I think the expectation is to get say `fe80::1ff:fe23:4567:890a` (without zone index) and not say `fe80::1ff:fe23:4567:890a%eth2 ` or `fe80::1ff:fe23:4567:890a%3 `when doing `ipv6_addr.ToString()` :)
ACKs for top commit:
MarcoFalke:
review ACK 63631beef6a0046390469971adf4500718ab34ad
Tree-SHA512: 06863d1edfb9ad1ca9bcae09cf3f0f47b58bb29d222b70799c3dc059b96452889026e4b99b132782846d9896e3e798d17c7f9406e0e6a0bec1bffc6edb54e9df
## Issue being fixed or feature implemented
We need some network that mimics v20 governance budget changes a bit
better. All our networks _lower_ the budget after v20 activation while
mainnet would actually rise it.
## What was done?
Reuse `nHighSubsidyBlocks` as a starting point for a fixed nSubsidyBase
value to better mimic mainnet changes on v20.
## How Has This Been Tested?
That's a devnet-only change, so no testing yet
## Breaking Changes
Won't sync on old devnets after these changes
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
---------
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
It's partial due to this missing changes:
```
https://github.com/bitcoin/bitcoin/pull/25233/files#diff-4cb884d03ebb901069e4ee5de5d02538c40dd9b39919c615d8eaa9d364bbbd77L632
```
cc61bc2e19b1c8cb32778ef42746d32b02cc2671 compat: remove glibcxx sanity checks (fanquake)
Pull request description:
These checks were added in #4339, (see also #4081), to test
our back-compat stubs, however, those stubs no-longer exist (#22930),
meaning that these checks are now just testing some specific standard
library behaviour, without a particular rationale, or reason, compared
to any other standard library functionlity we use.
There has also been some discussion about our sanity checks in the
context of the libbitcoinkernel refactoring, see https://github.com/bitcoin/bitcoin/pull/25065#discussion_r880668218.
Removing the checks removes the need to worry about atleast the
glibcxx checks.
Also remove the list of checks from the doc in `init.h`, because it is
incomplete, and anyone who wants to know what checks are included can
look at the function.
Guix Build (arm64):
```bash
e18a81e25b4707cbe113fb4d3ba2459013c1178e7cecfe446e4f14ee5ecd2ce8 guix-build-cc61bc2e19b1/output/arm-linux-gnueabihf/SHA256SUMS.part
9928cc38b79f827018cba0bdde98666b31806afcc79dd95a00acb8e153c36eec guix-build-cc61bc2e19b1/output/arm-linux-gnueabihf/bitcoin-cc61bc2e19b1-arm-linux-gnueabihf-debug.tar.gz
ebf4635ba4688899ae62e4bb17ebb2afb25c538c4a8068ef515920fd4e43754e guix-build-cc61bc2e19b1/output/arm-linux-gnueabihf/bitcoin-cc61bc2e19b1-arm-linux-gnueabihf.tar.gz
74c7e35b47c6d101fda7205f144d37150329b4c360db09d37b8c1437f3390898 guix-build-cc61bc2e19b1/output/arm64-apple-darwin/SHA256SUMS.part
6e12643b17be9326f1d873dfe51a52c082671540792877af624b42ca9f6e1791 guix-build-cc61bc2e19b1/output/arm64-apple-darwin/bitcoin-cc61bc2e19b1-arm64-apple-darwin-unsigned.dmg
1d86d0416c7a50afd7bd8d850f416b7c7277464ccc95e4dae53b5b59415fc83d guix-build-cc61bc2e19b1/output/arm64-apple-darwin/bitcoin-cc61bc2e19b1-arm64-apple-darwin-unsigned.tar.gz
84070843f23839e7191ad3a667eb63c45f668eb95afbfb3fcdfb8363320f67d4 guix-build-cc61bc2e19b1/output/arm64-apple-darwin/bitcoin-cc61bc2e19b1-arm64-apple-darwin.tar.gz
bf6ccd7b8c40476b1dc52b491757313ea3e96c43a01c8aabaf39f94dc1837329 guix-build-cc61bc2e19b1/output/dist-archive/bitcoin-cc61bc2e19b1.tar.gz
25e7e1ff7d8de38632abf9926343c8ba556209f3d03109c92864ffe72813a05f guix-build-cc61bc2e19b1/output/powerpc64-linux-gnu/SHA256SUMS.part
d0398de83841607b1bf921d4553b30ad5e2d70d0570e96a2eaaf2762e1103c79 guix-build-cc61bc2e19b1/output/powerpc64-linux-gnu/bitcoin-cc61bc2e19b1-powerpc64-linux-gnu-debug.tar.gz
f09cdc2ac2a2bb644f4749f3d74b5210ddb531594c33d127a907f0223e7793e5 guix-build-cc61bc2e19b1/output/powerpc64-linux-gnu/bitcoin-cc61bc2e19b1-powerpc64-linux-gnu.tar.gz
ef36a68ef4e5ee9b311df40062cd2296f897e7b1550e39e0643601cd7d469010 guix-build-cc61bc2e19b1/output/powerpc64le-linux-gnu/SHA256SUMS.part
937b600a2b86304ccc5b6c71a7eaf8aa5e2020592724cef6a933a1955995480b guix-build-cc61bc2e19b1/output/powerpc64le-linux-gnu/bitcoin-cc61bc2e19b1-powerpc64le-linux-gnu-debug.tar.gz
eca4eec41e71fdf7a7b0fa4065afa49c47d3b9541ed2cb4d083ad4a0de102e37 guix-build-cc61bc2e19b1/output/powerpc64le-linux-gnu/bitcoin-cc61bc2e19b1-powerpc64le-linux-gnu.tar.gz
981c0968c19905925a599cff357ec259c1e806bdb7691c7b52039be450bdad7c guix-build-cc61bc2e19b1/output/riscv64-linux-gnu/SHA256SUMS.part
89c709967f9a157256281fbf682aad246f2eaad9c2f1797c2787253cbabe12f8 guix-build-cc61bc2e19b1/output/riscv64-linux-gnu/bitcoin-cc61bc2e19b1-riscv64-linux-gnu-debug.tar.gz
454cd830dd382e176f5a23041fc33f93937668245481b0dd29fc04882d9528eb guix-build-cc61bc2e19b1/output/riscv64-linux-gnu/bitcoin-cc61bc2e19b1-riscv64-linux-gnu.tar.gz
e0812c2dc492e5c5f06e3685d19da8fb29ed38d3b32821d293ef01cb4fefbd79 guix-build-cc61bc2e19b1/output/x86_64-apple-darwin/SHA256SUMS.part
0e7d4241d8ac882a8091fa00a7813db87a3e5afec59627e45b6c910cfdd4a7b0 guix-build-cc61bc2e19b1/output/x86_64-apple-darwin/bitcoin-cc61bc2e19b1-x86_64-apple-darwin-unsigned.dmg
3faaca046cbb2642445a7dd1f389ed7bf94a65de8372441c36d5cb79c030ce31 guix-build-cc61bc2e19b1/output/x86_64-apple-darwin/bitcoin-cc61bc2e19b1-x86_64-apple-darwin-unsigned.tar.gz
73080f032a42db679baf0d09619671ac5b9d85be84a68bdd6b6709eb0e6465bd guix-build-cc61bc2e19b1/output/x86_64-apple-darwin/bitcoin-cc61bc2e19b1-x86_64-apple-darwin.tar.gz
07b6e1b6291404bca1044df4a45b6958b882ffb88c143ba98f1959960a394897 guix-build-cc61bc2e19b1/output/x86_64-linux-gnu/SHA256SUMS.part
16b455f62398f4aa0d3821abb1cceb8151e31c2664e3f974a764a5b8702b50f3 guix-build-cc61bc2e19b1/output/x86_64-linux-gnu/bitcoin-cc61bc2e19b1-x86_64-linux-gnu-debug.tar.gz
3c1a3a6a343f17b83f3b3d47e9426eccd2d0bcc7f824cd958fcf2cf06cdc3276 guix-build-cc61bc2e19b1/output/x86_64-linux-gnu/bitcoin-cc61bc2e19b1-x86_64-linux-gnu.tar.gz
f05afa688ea7211b0049555385fb2acc26986e24d8d00893389160e07037e693 guix-build-cc61bc2e19b1/output/x86_64-w64-mingw32/SHA256SUMS.part
8bcbae67dd0746c42e1e7c7db67725a69289b08e9aa97b873d443d0aa355615d guix-build-cc61bc2e19b1/output/x86_64-w64-mingw32/bitcoin-cc61bc2e19b1-win64-debug.zip
efa45e3b76e5ae08a8392d58e741325df572d92c7dd69b65d876cdcda541d2fc guix-build-cc61bc2e19b1/output/x86_64-w64-mingw32/bitcoin-cc61bc2e19b1-win64-setup-unsigned.exe
3a8c2461ca826138c3017d06279a79b4c6bee2a507ad362aa6e424f76678596c guix-build-cc61bc2e19b1/output/x86_64-w64-mingw32/bitcoin-cc61bc2e19b1-win64-unsigned.tar.gz
e56ae4f609d4e6a3ca5917a4bb763c91012ece2d236d6b62a666358791e43525 guix-build-cc61bc2e19b1/output/x86_64-w64-mingw32/bitcoin-cc61bc2e19b1-win64.zip
```
ACKs for top commit:
MarcoFalke:
lgtm ACK cc61bc2e19b1c8cb32778ef42746d32b02cc2671
laanwj:
Concept and code review ACK cc61bc2e19b1c8cb32778ef42746d32b02cc2671
Tree-SHA512: 3da6aba44eef3f864fcbe897db1faa964923756e68c6a713e444b5d01c6d3542c3d7ca26678760e81a7a9e3cd40bd90622d0a7b697c27166817ba4f1023661ef
705c1f0648c72aa97e0ee699ff9a3da23fc9bd61 qt, refactor: Fix 'buttonClicked is deprecated' warnings (Hennadii Stepanov)
c2f4e5ea1d6f01713ac69aaf6018884028aa55bd qt, refactor: Fix 'split is deprecated' warnings (Hennadii Stepanov)
8e12d6996116e786e928077b22d9f47cee27319e qt, refactor: Fix 'QFlags is deprecated' warnings (Hennadii Stepanov)
fa5749c805878304c107bcae0ae5ffa401dc7c4d qt, refactor: Fix 'pixmap is deprecated' warnings (Hennadii Stepanov)
b02264cb5dfcef50eec8a6346471cbaa25370e00 qt, refactor: Fix 'QDateTime is deprecated' warnings (Hennadii Stepanov)
Pull request description:
[What's New in Qt 5.15](https://doc.qt.io/qt-5/whatsnew515.html#deprecated-modules):
> To help preparing for the transition to Qt 6, numerous classes and member functions that will be removed from Qt 6.0 have been marked as deprecated in the Qt 5.15 release.
Fixes#36
ACKs for top commit:
jonasschnelli:
utACK 705c1f0648c72aa97e0ee699ff9a3da23fc9bd61
promag:
Tested ACK 705c1f0648c72aa97e0ee699ff9a3da23fc9bd61 on macos with Apple clang version 11.0.3 (clang-1103.0.32.62) and brew qt 5.15.1.
Tree-SHA512: 29e00535b4583ceec0dfb29612e86ee29bdea13651b548c6d22167917a4a10464af49160a12b05151030699f690f437ebb9c4ae9f130f66a722415222165b44f
86b1ab64b1a5b56518787ef16ea54ddbbc97d83e refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date (Hennadii Stepanov)
Pull request description:
As all deprecated warning in Qt 5.15.0 were eliminated in #46, Qt 5.15.1 introduced another one that is fixed in this PR.
Required for https://github.com/bitcoin/bitcoin/pull/20182.
Details in Qt docs:
- https://doc.qt.io/qt-5/qdatetime.html#toString-1
- https://doc.qt.io/qt-5/qdate.html#toString-1
ACKs for top commit:
jarolrod:
Tested ACK 86b1ab6 on MacOS 10.15.7 and Arch Linux both with Qt 5.15.1
jonasschnelli:
Tested ACK 86b1ab64b1a5b56518787ef16ea54ddbbc97d83e
Tree-SHA512: 1dbba8ee70c895bf58317172a9901cdbe5503b1d6258f51caaae88d88d332d9fbd4697c995192d31e3618ddfd532c5f5881289b3af1184422e5a9263a1224115
30cc1c6609ad7868f73e88afe0b0233d395ec08c refactor: Drop `owns_lock()` call (Hennadii Stepanov)
bff4e068b69edd40a00466156f860bde2df29268 refactor: Do not discard `try_lock()` return value (Hennadii Stepanov)
Pull request description:
Microsoft's C++ Standard Library uses the `[[nodiscard]]` attribute for `try_lock()`.
See: https://github.com/microsoft/STL/blob/main/stl/inc/mutex
This change allows to drop the current suppression for the warning C4838 and helps to prevent the upcoming warning C4858.
See: 539c26c923Fixesbitcoin/bitcoin#26017.
Split from bitcoin/bitcoin#25819.
ACKs for top commit:
vasild:
ACK 30cc1c6609ad7868f73e88afe0b0233d395ec08c
Tree-SHA512: ce17404e1c78af4f763129753caf8e5a0e1c91ba398778fe912f9fcc56a847e8112460d1a1a35bf905a593b7d8e0b16c6b099ad74976b67dca5f4f3eda6ff621
## Issue being fixed or feature implemented
Having `<protxhash> is not connected to us, badConnection=0` doesn't
help when we don't expect it to be connected 🤷♂️
## What was done?
## How Has This Been Tested?
## 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)_
## Issue being fixed or feature implemented
MNs don't really vote NO on triggers that do not match their local
candidates because:
1. they bail out too early when they see that they are not the payee
2. the hash for objects to vote NO on was picked incorrectly.
## What was done?
Moved voting out of `CreateGovernanceTrigger` and into its own
`VoteGovernanceTriggers`. Refactored related code to use `optional`
while at it, dropped useless/misleading `IsValid()` call. Added some
safety belts, logging, tests.
## How Has This Been Tested?
Run tests.
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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)_
## Issue being fixed or feature implemented
## What was done?
## How Has This Been Tested?
reindexed
## 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)_
## Issue being fixed or feature implemented
There's too much spamming log items related to new v20 features: credit
pool, asset locks, EHF manager, EHF Signaling for MN_RR.
Some logs are still spamming after this PR but related code is not
changed here https://github.com/dashpay/dash/pull/5658
## What was done?
- Removed some log items, tidy-up other.
- logs that supposed to appear for each block are moved to new
categories EHF and CREDITPOOL
## How Has This Been Tested?
Run unit/functional tests, reviewed log output
## 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
## Issue being fixed or feature implemented
No need to log things like `punished MN <protxhash>, penalty 515->515
(max=515)`
(check block 907818 on testnet, it has a lot of these)
## What was done?
## How Has This Been Tested?
n/a
## 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)_
It fixes this and similar warnings:
```
qt/test/trafficgraphdatatests.cpp:145:23: warning: ‘int qrand()’ is deprecated: use QRandomGenerator instead [-Wdeprecated-declarations]
145 | int in = qrand() % 1000;
| ~~~~~^~
```
Call of `qsrand` is not needed because QRandomGenerator is already randomly initialized
