Commit Graph

24147 Commits

Author SHA1 Message Date
PastaPastaPasta
b1e9e05c7f
Merge pull request #5750 from ogabrielides/v20.0.2_release
backport: v20.0.2 backports and release
2023-12-05 10:43:50 -06:00
Odysseas Gabrielides
47113c9aa3 docs: archive v20.0.1 release notes and create v20.0.2 release notes 2023-12-05 16:29:48 +02:00
UdjinM6
02c5edc196 fix: Start LLMQContext early to let VerifyDB() check ChainLock signatures in coinbase (#5752)
## 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)_
2023-12-05 16:29:05 +02:00
Konstantin Akimov
bd926a52a0 fix: drop useless mutex cs_llmq_vbc to avoid deadlock (#5749)
## 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>
2023-12-04 18:05:10 +02:00
UdjinM6
bab3aa13ad fix: actually use to_calculate stack in CMNHFManager::GetForBlock (#5747)
## 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)_
2023-12-04 18:04:38 +02:00
Konstantin Akimov
2e01672b89 fix: assertion in CMNHFManager due to missing data in evoDB (#5736)
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)_
2023-12-04 18:04:11 +02:00
PastaPastaPasta
18b580591c Merge pull request #5740 from knst/bp-versionbits
backport: bitcoin#19438 Introduce deploymentstatus (versionbits improvements)
2023-12-04 17:52:20 +02:00
UdjinM6
5e8140d23f fix: Redefine keepOldKeys and align quorum and dkgsession key storage depths (#5748)
## 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)_
2023-12-04 17:13:32 +02:00
UdjinM6
f8e88adadc fix: avoid a crash on -reindex-chainstate (#5746)
## 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)_
2023-12-04 17:12:33 +02:00
UdjinM6
5132c11cb0 fix: use correct interruption condition in StartCachePopulatorThread (#5732)
## 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)_
2023-12-04 17:06:54 +02:00
UdjinM6
4092abc10d fix: Improve quorum data caching and cleanup (#5731)
## 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>
2023-12-04 17:06:28 +02:00
UdjinM6
96d4a30510 ci: Bump Guix build timeout and implement cacheing (#5727)
## Issue being fixed or feature implemented
Hopefully fixes issues like
>The job running on runner ubuntu-core-x64_i-05ed4263b8e049c7a has
exceeded the maximum execution time of 360 minutes

https://github.com/dashpay/dash/actions/runs/6932017275


https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes

## What was done?
Bump timeouts for the job itself and for the corresponding step. Also,
implemented caching for `.cache` and `depends` folders.

## How Has This Been Tested?
#5729


https://github.com/dashpay/dash/actions/runs/6996271543/job/19031968814?pr=5729

## 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)_
2023-12-04 17:05:52 +02:00
PastaPastaPasta
4660170eae Merge pull request #5726 from UdjinM6/bp_18742_28150
backport: bitcoin#18742, #28150
2023-12-04 17:05:28 +02:00
UdjinM6
330c5f9451 fix: should avoid implicit conversions in pushKV params (#5719)
## 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)_
2023-12-04 17:04:59 +02:00
PastaPastaPasta
7c966c9db0 Merge pull request #5718 from knst/mac-improvements
backport: bitcoin#24603, #26694, #24669, #22546, #22199, #25817 (mac build)
2023-12-04 17:04:30 +02:00
UdjinM6
a8573c942f fix: avoid crashes on "corrupted db" reindex attempts (#5717)
## 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)_
2023-12-04 17:03:50 +02:00
Odysseas Gabrielides
3d9410377f chore: bump version to 20.0.2 2023-12-04 16:56:49 +02:00
PastaPastaPasta
00f3db115d
Merge pull request #5714 from UdjinM6/bp5713
backport: backport 5713 to v20.x
2023-11-16 13:24:23 -06:00
UdjinM6
ea1f5241f9
fix: make CONFIGFLAGS optional (#5713)
## Issue being fixed or feature implemented
make it possible to run `./contrib/guix/guix-build` without specifying
`CONFIGFLAGS`

## What was done?

## How Has This Been Tested?
run `./contrib/guix/guix-build` 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)_
2023-11-16 22:21:16 +03:00
PastaPastaPasta
702bc49ac2
Merge pull request #5712 from PastaPastaPasta/20.0.1-backports
backport: v20.0.1 backports and release
2023-11-16 12:56:30 -06:00
pasta
39b315aef7
chore: bump version to 20.0.1 2023-11-16 12:42:35 -06:00
pasta
f914cdd52b
docs: archive v20.0.0 release notes and create v20.0.1 release notes 2023-11-16 12:41:31 -06:00
PastaPastaPasta
42b5b15521
build(guix): add debug symbols for osx (#5708)
## Issue being fixed or feature implemented
Add debug symbols for Darwin

## What was done?
Added Darwin debug symbols and combine them as output

## How Has This Been Tested?
guix build

## Breaking Changes
  _Please describe any breaking changes your code introduces_


## 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>
2023-11-16 12:39:24 -06:00
UdjinM6
c49628de54
fix: should not notify about mnlist changes while ConnectBlock isn't done yet (#5711)
## 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)_
2023-11-16 12:37:07 -06:00
Konstantin Akimov
259ad319d9
chore: inacuracies in release notes for v20 and v19 (#5709)
## What was done?
Fixes some inaccuracies for release notes for v20.0.0, for v19.2.0.


## 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
2023-11-16 12:19:29 -06:00
UdjinM6
8428a581c2
fix: add missing log categories (#5707)
## 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)_
2023-11-16 12:19:20 -06:00
UdjinM6
f796a4473d
build: let additional configure params to be passed into guix (#5705)
## Issue being fixed or feature implemented
Make it possible to pass additional configure params into Guix. This
could be used to setup various sets of nightly/debug builds which could
then be deployed automagically to catch potential issues early.

## What was done?


## How Has This Been Tested?
`CONFIGFLAGS="--enable-debug" HOSTS="x86_64-linux-gnu"
./contrib/guix/guix-build`

## 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)_
2023-11-16 12:19:09 -06:00
PastaPastaPasta
df79078a2e
chore: set release version to true; set rc to 0 (#5695)
## Issue being fixed or feature implemented
Bump release to true; rc to 0

This should be the final PR merged to v20.x branch

## What was done?


## How Has This Been Tested?


## Breaking Changes


## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] 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)_
2023-11-14 09:17:48 -06:00
UdjinM6
3be7979c04
docs: add v20.0.0 release notes, archive v19.3.0 and drop partial ones (#5674)
## Issue being fixed or feature implemented
NOTE: this PR is for v20.x branch, to be merged as the last one before
v20 release.

## What was done?


## How Has This Been Tested?


## Breaking Changes

## 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
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
2023-11-14 09:16:26 -06:00
PastaPastaPasta
4a639eb7bd
Merge pull request #5697 from UdjinM6/translations202311
chore: Translations2023-11
2023-11-14 09:09:19 -06:00
UdjinM6
acfff1a060 ru 2023-11-14 09:08:39 -06:00
UdjinM6
358692e2e5 make translate 2023-11-14 09:08:39 -06:00
PastaPastaPasta
402e937d29
fix: enable the mn_rr hard fork in v20 so that a v20.1 in the future may activate mn_rr (#5699)
## 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>
2023-11-14 09:08:06 -06:00
PastaPastaPasta
6715fc2075
Merge pull request #5692 from UdjinM6/mainnet_seeds
chore: update mainnet chainparams and seeds
2023-11-13 10:13:26 -06:00
UdjinM6
696f8a806a chore: define v20 start/timeout on mainnet 2023-11-13 10:13:12 -06:00
UdjinM6
4b26efa102 chore: update mainnet chainparams 2023-11-13 10:13:12 -06:00
UdjinM6
7e55f09a98 chore: update mainnet seeds
```
cd contrib/seeds
dash-cli protx list valid 1 > protx.txt
./makeseeds.py protx.txt > nodes_main.txt
./generate-seeds.py . > ../../src/chainparamsseeds.h
```
2023-11-13 10:13:12 -06:00
UdjinM6
c2db29439a
fix: rename SPORK_24_EHF to SPORK_24_TEST_EHF, make sure it has no effect on mainnet (#5691)
## 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)_
2023-11-13 10:03:46 -06:00
UdjinM6
704c594237
fix: some fixes for block payee validation and corresponding tests (#5684)
## 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)_
2023-11-13 10:02:52 -06:00
Odysseas Gabrielides
c2354fb55f
fix: keep platform quorum data for 2 months (#5690)
## 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>
2023-11-13 10:02:15 -06:00
UdjinM6
b1d249d102
fix: avoid some crashes on invalidateblock (#5683)
## 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)_
2023-11-11 13:14:26 +03:00
PastaPastaPasta
6e639c7ac3
refactor: use more gsl::not_null in utils.h and deterministicmns.h (#5651)
## 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)_
2023-11-10 08:33:21 -06:00
Odysseas Gabrielides
d5b2c260a4
test: ensure that mining is possible without CL info (#5689)
## Issue being fixed or feature implemented
With DIP29 added to v20, miners include best CL Signature in CbTx.
The purpose of this test, is to ensure that mining is still possible
when CL information isn't available.
In such case, miners are expected to copy best CL Signature from CbTx of
previous block.

## What was done?
Two scenarios are implemented:

- Add dynamically a node, make sure `getbestchainlock()` fails, let it
mine a block.
- Disable `SPORK_19_CHAINLOCKS_ENABLED`, add dynamically a node, make
sure `getbestchainlock()` fails, let it mine a block.

In both tests, we make sure the block is accepted by everyone and that
the `bestCLSignature` in CbTx is copied from previous block.

## How Has This Been Tested?
`feature_llmq_chainlocks.py`

## 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
- [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 _(for repository
code-owners and collaborators only)_

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2023-11-10 08:32:01 -06:00
Konstantin Akimov
216a5f7563
refactor: make MNActivationHeight in Params() indeed constant (#5658)
## 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>
2023-11-10 08:31:12 -06:00
Konstantin Akimov
8022b4497a
feat: improving unit tests for Basic BLS and enforcing Basic BLS for Evo Nodes (#5463)
## 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
2023-11-08 10:30:39 -06:00
UdjinM6
ab56dcf34e
docs: update man pages (#5672)
## Issue being fixed or feature implemented

## What was done?
`./contrib/devtools/gen-manpages.sh` and drop `rc2` and `dirty` suffixes

## 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)_
2023-11-07 08:04:39 -06:00
Odysseas Gabrielides
c293593be2
test: v20 earlier activation for regtest (#5668)
## 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)_
2023-11-07 08:03:03 -06:00
PastaPastaPasta
7bae092519
Merge pull request #5661 from knst/fix-backport-21689
backport: bitcoin#21689 (fix unit test failure test/net_tests.cpp:275)
2023-11-07 07:54:21 -06:00
MarcoFalke
944a4d758d Merge #21689: test: Remove intermittently failing and not very meaningful BOOST_CHECK in cnetaddr_basic
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
2023-11-07 07:54:03 -06:00
UdjinM6
343c25594f
feat!: reuse nHighSubsidyBlocks as a starting point for a fixed nSubsidyBase value to better mimic mainnet (#5664)
## 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>
2023-11-07 07:51:23 -06:00