Commit Graph

24163 Commits

Author SHA1 Message Date
Konstantin Akimov
722206c125
docs: release notes for 20.0.4 and archiving old one 2024-01-12 00:48:31 +07:00
PastaPastaPasta
cbef7f2116
feat: use a self-signed windows code signing certificate instead of e… (#5814)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

## Issue being fixed or feature implemented
Implement a new code-singing certificate for windows. 

Previously we used a certificate issued by DigiCert, however that
certificate recently expired. A renewed certificate would cost roughly
$200/year at the cheapest CAs and $370/year with DigiCert. EV
certificates are relatively novel types of certificates that start out
with positive reputation, reducing smart screen popups for users. EV
certificates start at $270/year.

As a result we had (/have) 4 options:
1. Get a new code signing certificate from a trusted CA
- - Pro: Certificate gains reputation over time in smart screen and
binaries are signed
- - Pro: Shows "Verified Publisher" and "Dash Core Group Inc" on install
- - Con: Costs, feels manipulative to pay at least $600 simply for
someone to sign a certificate
2. Get a new EV code signing certificate
- - Pro: Certificate starts with good reputation and gains reputation
over time
- - Con: Even greater costs for a signature that says that we are from
Dash Core Group
3. Continue signing with the expired certificate
- - Con: This is, it has been discovered, a terrible idea and these
binaries are treated worse than unsigned binaries
4. Deliver unsigned windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: Easy, is what it says on the tin
- - Con: Binaries are completely unsigned, could be tampering or
corruption issues that go undetected
- - Con: Will visibly state "Unknown Publisher"
5. Deliver self-signed windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: *Possibility* that certificate will gain reputation over time
as users download binaries signed by it. It may also be that only
certificates issued by a CA will gain reputation over time.
- - Pro: Binaries are still signed
- - Pro: Users have the option to import certificate into keychain to
remove "Unknown Publisher"
- - Pro: In limited testing, install is sometimes is treated better than
unsigned, otherwise is treated the same
- - Con: may appear sketchy, as Root CA is not a trusted Root CA
- - Con: will display "Unknown Publisher" to most users
- - Con: greater potential uncertainty around future changes to
treatment of self signing systems

Based on the above discussion and testing, the best route currently is
option 5; that is what this PR implements. In the future it may make
sense to move towards a codesigning certificate issued by a trusted CA.

The root certificate authority has the following information

![image](https://github.com/dashpay/dash/assets/6443210/66a90588-9bd9-4fe5-902c-04e8d1e47b6f)
with a sha256 fingerprint of `46 84 FF 27 11 D7 C8 C5 BB FA D1 55 41 B3
F0 43 77 97 AC 67 4C 32 19 AE B4 E7 15 11 1F BB 42 A0`

The code signing certificate is issued by the root CA, has a common name
of "Dash Core Windows Signing" and a sha256 fingerprint of `1A 09 54 6E
D3 81 E9 FC AD 62 44 32 35 40 39 FF 5F A7 30 0E 5E 03 C4 E0 96 5A 62 AA
19 2B 79 EE`. This certificate is only authorized for the purpose of
code signing.

## What was done?

## How Has This Been Tested?
Multiple users installing binaries of type 1,3,4 and 5. 

## Breaking Changes
This new windows signing certificate should be documented in the release
notes.

## 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)_


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEKVkDYuyHioH9PCArUlJ77avoeYQFAmWfAbUACgkQUlJ77avo
eYTSCBAAuDEoWABdonIMs/4RaYP+DGTULltRu9CHBAqYuksXrl/4iV0r17DPSWWW
L/5vLNAUTI47Tsa7R45ZPb0hR8VPMBkvxTQipKBYK7vZpwefcR4VOprEBJJ0Bl3g
ZHtAVjZbcANEIAW3SlaiOgWbxWGKfDyM7gN3aNfoidMFBefbcYKEttuAGCnktWRI
Y3eLMGPCpxOVB0O1nLU+pzwixAWXOeVChiK31ecFfQrF3JmUc12yiFUI+OJTogg4
0G2GMIQYHiVwclj8hSWT/yZfjcyxXdLYqkmH4Nr5mye39hRI2aUQEkmkYOy8pjcB
ykKLg8JpUg/zg6GSuS6mFJnd5NHq5iSBxSRHPfR8xij1xFpmdgAaNCw4/6j9PEXB
l8cfuJ7hgX3yX09L4p2E4t7MYpM8igaenAIWAK37hmKs1WADBmaj/nf6ThKhjvzI
2GR0FOzm6Is36KYvdUQJDE0g70g31SvGy+qjlcK49MtX6BvecYt+dg8AaNZ5FIn7
d1kFI4NXM6JX2WdiHMenz5d+oFYRS/P1sXjQ1wtl9HSkiZQQkEBbgiWXfh+EXjpW
fNc8cej2LLCNZlhVcpffF8UaINsMTZVQsEGWGInjSi5eCs/YNrqL8XDdC/8mmZCu
cNvp0QBtQ+4lpbUSdhFUdgic0MRCsdeHuYIBfvPJN9tl8McbknA=
=kL6E
-----END PGP SIGNATURE-----
2024-01-11 22:49:10 +07:00
Konstantin Akimov
3796c4b616
chore: drop version from README.md which is not really useful (#5811)
## What was done?
drop version from README.md which is not really useful.

And we will care about one less thing during each release

## 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
2024-01-11 22:48:39 +07:00
PastaPastaPasta
eab0656075
Merge pull request #5797 from knst/builder-keys
chore: update builder keys for pasta, udjin
2024-01-10 21:54:44 +07:00
UdjinM6
acd3ce7783
fix: ignore triggers from the past when voting (#5798)
## 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)_
2024-01-10 19:50:03 +07:00
Konstantin Akimov
4ebdaf69bc
fix: withdrawal (asset unlock) txes to use Platform Quorum on RegTest (#5800)
## 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
2024-01-10 19:49:54 +07:00
UdjinM6
d0d4669479
build: Disable miner for Windows binaries built via Guix (#5801)
## Issue being fixed or feature implemented
We had this in Gitian
https://github.com/dashpay/dash/blob/master/contrib/gitian-descriptors/gitian-win.yml#L38.
We also had it for macos
https://github.com/dashpay/dash/blob/master/contrib/gitian-descriptors/gitian-osx.yml#L42
but it looks like it's no longer an issue there (or at least I did not
see anyone complaining about it).

## What was done?
tweak `CONFIGFLAGS` for `mingw` host

## 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)_
2024-01-10 19:49:34 +07:00
PastaPastaPasta
c50a7d1a7b
Merge pull request #5785 from ogabrielides/20.0.3-release
backport: v20.0.3 backports and release
2023-12-24 12:16:21 -06:00
Odysseas Gabrielides
3192d8c9f8
docs: archive v20.0.2 release notes and create v20.0.3 release notes 2023-12-24 12:04:42 -06:00
Odysseas Gabrielides
12649070f8
chore: bump version to 20.0.3 2023-12-24 12:04:42 -06:00
UdjinM6
b3a1c8b9c6
fix: ScanQuorums should not start cache population for outdated quorums (#5784)
## 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)_
2023-12-24 12:04:42 -06:00
PastaPastaPasta
71e7658fdf
refactor: pass large structure by const reference on every RPC call (#5780) 2023-12-24 12:04:41 -06:00
PastaPastaPasta
234d090045
Merge pull request #5152 from vijaydasmp/bp21_14
backport: Merge bitcoin#18814, 18781
2023-12-24 12:04:41 -06:00
UdjinM6
3e5a6ef649
fix(rpc): pass blockhash into TxToJSON so that getspecialtxes could show correct instantlock/chainlock values (#5774)
## 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)_
2023-12-24 12:04:41 -06:00
UdjinM6
ee4c27d0b9
fix: Improve quorum caching (again) (#5761)
## 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
2023-12-24 12:04:41 -06:00
PastaPastaPasta
f0feb36ce3
Merge pull request #5759 from UdjinM6/bp26532
backport: partial merge bitcoin#26532: wallet: bugfix, invalid crypted key "checksum_valid" set
2023-12-24 12:04:40 -06:00
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