dash/src/dsnotificationinterface.h

54 lines
2.5 KiB
C
Raw Normal View History

// Copyright (c) 2015 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
#ifndef BITCOIN_DSNOTIFICATIONINTERFACE_H
#define BITCOIN_DSNOTIFICATIONINTERFACE_H
Backport 11651 (#3358) * scripted-diff: Replace #include "" with #include <> (ryanofsky) -BEGIN VERIFY SCRIPT- for f in \ src/*.cpp \ src/*.h \ src/bench/*.cpp \ src/bench/*.h \ src/compat/*.cpp \ src/compat/*.h \ src/consensus/*.cpp \ src/consensus/*.h \ src/crypto/*.cpp \ src/crypto/*.h \ src/crypto/ctaes/*.h \ src/policy/*.cpp \ src/policy/*.h \ src/primitives/*.cpp \ src/primitives/*.h \ src/qt/*.cpp \ src/qt/*.h \ src/qt/test/*.cpp \ src/qt/test/*.h \ src/rpc/*.cpp \ src/rpc/*.h \ src/script/*.cpp \ src/script/*.h \ src/support/*.cpp \ src/support/*.h \ src/support/allocators/*.h \ src/test/*.cpp \ src/test/*.h \ src/wallet/*.cpp \ src/wallet/*.h \ src/wallet/test/*.cpp \ src/wallet/test/*.h \ src/zmq/*.cpp \ src/zmq/*.h do base=${f%/*}/ relbase=${base#src/} sed -i "s:#include \"\(.*\)\"\(.*\):if test -e \$base'\\1'; then echo \"#include <\"\$relbase\"\\1>\\2\"; else echo \"#include <\\1>\\2\"; fi:e" $f done -END VERIFY SCRIPT- Signed-off-by: Pasta <pasta@dashboost.org> * scripted-diff: Replace #include "" with #include <> (Dash Specific) -BEGIN VERIFY SCRIPT- for f in \ src/bls/*.cpp \ src/bls/*.h \ src/evo/*.cpp \ src/evo/*.h \ src/governance/*.cpp \ src/governance/*.h \ src/llmq/*.cpp \ src/llmq/*.h \ src/masternode/*.cpp \ src/masternode/*.h \ src/privatesend/*.cpp \ src/privatesend/*.h do base=${f%/*}/ relbase=${base#src/} sed -i "s:#include \"\(.*\)\"\(.*\):if test -e \$base'\\1'; then echo \"#include <\"\$relbase\"\\1>\\2\"; else echo \"#include <\\1>\\2\"; fi:e" $f done -END VERIFY SCRIPT- Signed-off-by: Pasta <pasta@dashboost.org> * build: Remove -I for everything but project root Remove -I from build system for everything but the project root, and built-in dependencies. Signed-off-by: Pasta <pasta@dashboost.org> # Conflicts: # src/Makefile.test.include * qt: refactor: Use absolute include paths in .ui files * qt: refactor: Changes to make include paths absolute This makes all include paths in the GUI absolute. Many changes are involved as every single source file in src/qt/ assumes to be able to use relative includes. Signed-off-by: Pasta <pasta@dashboost.org> # Conflicts: # src/qt/dash.cpp # src/qt/optionsmodel.cpp # src/qt/test/rpcnestedtests.cpp * test: refactor: Use absolute include paths for test data files * Recommend #include<> syntax in developer notes * refactor: Include obj/build.h instead of build.h * END BACKPORT #11651 Remove trailing whitespace causing travis failure * fix backport 11651 Signed-off-by: Pasta <pasta@dashboost.org> * More of 11651 * fix blockchain.cpp Signed-off-by: pasta <pasta@dashboost.org> * Add missing "qt/" in includes * Add missing "test/" in includes * Fix trailing whitespaces Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com> Co-authored-by: Russell Yanofsky <russ@yanofsky.org> Co-authored-by: MeshCollider <dobsonsa68@gmail.com> Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2020-03-19 23:46:56 +01:00
#include <validationinterface.h>
class CConnman;
class CDeterministicMNManager;
class CGovernanceManager;
class CMasternodeSync;
refactor: subsume CoinJoin objects under CJContext, deglobalize coinJoin{ClientQueueManager,Server} (#5337) ## Motivation CoinJoin's subsystems are initialized by variables and managers that occupy the global context. The _extent_ to which these subsystems entrench themselves into the codebase is difficult to assess and moving them out of the global context forces us to enumerate the subsystems in the codebase that rely on CoinJoin logic and enumerate the order in which components are initialized and destroyed. Keeping this in mind, the scope of this pull request aims to: * Reduce the amount of CoinJoin-specific entities present in the global scope * Make the remaining usage of these entities in the global scope explicit and easily searchable ## Additional Information * The initialization of `CCoinJoinClientQueueManager` is dependent on blocks-only mode being disabled (which can be alternatively interpreted as enabling the relay of transactions). The same applies to `CBlockPolicyEstimator`, which `CCoinJoinClientQueueManager` depends. Therefore, `CCoinJoinClientQueueManager` is only initialized if transaction relaying is enabled and so is its scheduled maintenance task. This can be found by looking at `init.cpp` [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L1681-L1683), [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2253-L2255) and [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2326-L2327). For this reason, `CBlockPolicyEstimator` is not a member of `CJContext` and its usage is fulfilled by passing it as a reference when initializing the scheduling task. * `CJClientManager` has not used `CConnman` or `CTxMemPool` as `const` as existing code that is outside the scope of this PR would cast away constness, which would be unacceptable. Furthermore, some logical paths are taken that will grind to a halt if they are stored as `const`. Examples of such a call chains would be: * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoinClientSession::DoAutomaticDenominating > CCoinJoinClientSession::StartNewQueue > CConnman::AddPendingMasternode` which modifies `CConnman::vPendingMasternodes`, which is non-const behaviour * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoin::IsCollateralValid > AcceptToMemoryPool` which adds a transaction to the memory pool, which is non-const behaviour * There were cppcheck [linter failures](https://github.com/dashpay/dash/pull/5337#issuecomment-1685084688) that seemed to be caused by the usage of `Assert` in `coinjoin/client.h`. This seems to be resolved by backporting [bitcoin#24714](https://github.com/bitcoin/bitcoin/pull/24714). (Thanks @knst!) * Depends on #5546 --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com> Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-09-13 19:52:38 +02:00
struct CJContext;
struct LLMQContext;
class CDSNotificationInterface : public CValidationInterface
{
public:
explicit CDSNotificationInterface(CConnman& _connman,
refactor: using reference instead reference to unique_ptr with object (#5381) ## Issue being fixed or feature implemented Many objects created and functions called by passing `const std::unique_ptr<Obj>& obj` instead directly passing `Obj& obj` In some cases it is indeed needed, but in most cases it is just extra complexity that is better to avoid. Motivation: - providing reference to object instead `unique_ptr` is giving warranty that there's no `nullptr` and no need to keep it in mind - value inside unique_ptr by reference can be changed externally and instead `nullptr` it can turn to real object later (or in opposite) - code is shorter but cleaner Based on that this refactoring is useful as it reduces mental load when reading or writing code. `std::unique` should be used ONLY for owning object, but not for passing it everywhere. ## What was done? Replaced most of usages `std::unique_ptr<Obj>& obj` to `Obj& obj`. Btw, in several cases implementation assumes that object can be nullptr and replacement to reference is not possible. Even using raw pointer is not possible, because the empty std::unique_ptr can be initialized later somewhere in code. For example, in `src/init.cpp` there's called `PeerManager::make` and pass unique_ptr to the `node.llmq_ctx` that would be initialized way later. That is out of scope this PR. List of cases, where reference to `std::unique_ptr` stayed as they are: - `std::unique_ptr<LLMQContext>& llmq_ctx` in `PeerManagerImpl`, `PeerManager` and `CDSNotificationInterface` - `std::unique_ptr<CDeterministicMNManager>& dmnman` in `CDSNotificationInterface` Also `CChainState` have 3 references to `unique_ptr` that can't be replaced too: - `std::unique_ptr<llmq::CChainLocksHandler>& m_clhandler;` - `std::unique_ptr<llmq::CInstantSendManager>& m_isman;` - `std::unique_ptr<llmq::CQuorumBlockProcessor>& m_quorum_block_processor;` ## How Has This Been Tested? Run unit/functional tests. ## Breaking Changes No breaking changes, all of these changes - are internal APIs for Dash Core developers only. ## 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 - [x] 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-06-04 22:26:23 +02:00
CMasternodeSync& _mn_sync, const std::unique_ptr<CDeterministicMNManager>& _dmnman,
refactor: subsume CoinJoin objects under CJContext, deglobalize coinJoin{ClientQueueManager,Server} (#5337) ## Motivation CoinJoin's subsystems are initialized by variables and managers that occupy the global context. The _extent_ to which these subsystems entrench themselves into the codebase is difficult to assess and moving them out of the global context forces us to enumerate the subsystems in the codebase that rely on CoinJoin logic and enumerate the order in which components are initialized and destroyed. Keeping this in mind, the scope of this pull request aims to: * Reduce the amount of CoinJoin-specific entities present in the global scope * Make the remaining usage of these entities in the global scope explicit and easily searchable ## Additional Information * The initialization of `CCoinJoinClientQueueManager` is dependent on blocks-only mode being disabled (which can be alternatively interpreted as enabling the relay of transactions). The same applies to `CBlockPolicyEstimator`, which `CCoinJoinClientQueueManager` depends. Therefore, `CCoinJoinClientQueueManager` is only initialized if transaction relaying is enabled and so is its scheduled maintenance task. This can be found by looking at `init.cpp` [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L1681-L1683), [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2253-L2255) and [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2326-L2327). For this reason, `CBlockPolicyEstimator` is not a member of `CJContext` and its usage is fulfilled by passing it as a reference when initializing the scheduling task. * `CJClientManager` has not used `CConnman` or `CTxMemPool` as `const` as existing code that is outside the scope of this PR would cast away constness, which would be unacceptable. Furthermore, some logical paths are taken that will grind to a halt if they are stored as `const`. Examples of such a call chains would be: * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoinClientSession::DoAutomaticDenominating > CCoinJoinClientSession::StartNewQueue > CConnman::AddPendingMasternode` which modifies `CConnman::vPendingMasternodes`, which is non-const behaviour * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoin::IsCollateralValid > AcceptToMemoryPool` which adds a transaction to the memory pool, which is non-const behaviour * There were cppcheck [linter failures](https://github.com/dashpay/dash/pull/5337#issuecomment-1685084688) that seemed to be caused by the usage of `Assert` in `coinjoin/client.h`. This seems to be resolved by backporting [bitcoin#24714](https://github.com/bitcoin/bitcoin/pull/24714). (Thanks @knst!) * Depends on #5546 --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com> Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-09-13 19:52:38 +02:00
CGovernanceManager& _govman, const std::unique_ptr<LLMQContext>& _llmq_ctx,
const std::unique_ptr<CJContext>& _cj_ctx);
virtual ~CDSNotificationInterface() = default;
// a small helper to initialize current block height in sub-modules on startup
void InitializeCurrentBlockTip();
protected:
// CValidationInterface
void AcceptedBlockHeader(const CBlockIndex *pindexNew) override;
void NotifyHeaderTip(const CBlockIndex *pindexNew, bool fInitialDownload) override;
void SynchronousUpdatedBlockTip(const CBlockIndex *pindexNew, const CBlockIndex *pindexFork, bool fInitialDownload) override;
void UpdatedBlockTip(const CBlockIndex *pindexNew, const CBlockIndex *pindexFork, bool fInitialDownload) override;
void TransactionAddedToMempool(const CTransactionRef& tx, int64_t nAcceptTime) override;
void TransactionRemovedFromMempool(const CTransactionRef& ptx, MemPoolRemovalReason reason) override;
Merge #17477: Remove the mempool's NotifyEntryAdded and NotifyEntryRemoved signals e57980b4738c10344baf136de3e050a3cb958ca5 [mempool] Remove NotifyEntryAdded and NotifyEntryRemoved callbacks (John Newbery) 2dd561f36124972d2364f941de9c3417c65f05b6 [validation] Remove pool member from ConnectTrace (John Newbery) 969b65f3f527631ede1a31c7855151e5c5d91f8f [validation] Remove NotifyEntryRemoved callback from ConnectTrace (John Newbery) 5613f9842b4000fed088b8cf7b99674c328d15e1 [validation] Remove conflictedTxs from PerBlockConnectTrace (John Newbery) cdb893443cc16edf974f099b8485e04b3db1b1d7 [validation interface] Remove vtxConflicted from BlockConnected (John Newbery) 1168394d759b13af68acec6d5bfa04aaa24561f8 [wallet] Notify conflicted transactions in TransactionRemovedFromMempool (John Newbery) Pull request description: These boost signals were added in #9371, before we had a `TransactionRemovedFromMempool` method in the validation interface. The `NotifyEntryAdded` callback was used by validation to build a vector of conflicted transactions when connecting a block, which the wallet was notified of in the `BlockConnected` CValidationInterface callback. Now that we have a `TransactionRemovedFromMempool` callback, we can fire that signal directly from the mempool for conflicted transactions. Note that #9371 was implemented to ensure `-walletnotify` events were fired for these conflicted transaction. We inadvertently stopped sending these notifications in #16624 (Sep 2019 commit 7e89994). We should probably fix that, but in a different PR. ACKs for top commit: jonatack: Re-ACK e57980b ryanofsky: Code review ACK e57980b4738c10344baf136de3e050a3cb958ca5, no code changes since previous review, but helpful new code comments have been added and the PR description is now more clear about where the old code came from Tree-SHA512: 3bdbaf1ef2731e788462d4756e69c42a1efdcf168691ce1bbfdaa4b7b55ac3c5b1fd4ab7b90bcdec653703600501b4224d252cfc086aef28f9ce0da3b0563a69
2020-03-19 17:09:15 +01:00
void BlockConnected(const std::shared_ptr<const CBlock>& pblock, const CBlockIndex* pindex) override;
void BlockDisconnected(const std::shared_ptr<const CBlock>& pblock, const CBlockIndex* pindexDisconnected) override;
void NotifyMasternodeListChanged(bool undo, const CDeterministicMNList& oldMNList, const CDeterministicMNListDiff& diff, CConnman& connman) override;
void NotifyChainLock(const CBlockIndex* pindex, const std::shared_ptr<const llmq::CChainLockSig>& clsig) override;
private:
Eliminate remaining uses of g_connman in Dash-specific code. (#1635) This monstrous change eliminates all remaining uses of g_connman global variable in Dash-specific code. Unlike previous changes eliminating g_connman use that were isolated to particular modules, this one covers multiple modules simultaneously because they are so interdependent that change in one module was quickly spreading to others. This is mostly invariant change that was done by * changing all functions using g_connman to use connman argument, * changing all functions calling these functions to use connman argument, * repeating previous step until there's nothing to change. After multiple iterations, this process converged to final result, producing code that is mostly equivalent to original one, but passing CConnman instance through arguments instead of global variable. The only exception to equivalence of resulting code is that I had to create overload of CMasternodeMan::CheckAndRemove() method without arguments that does nothing just for use in CFlatDB<CMasternodeMan>::Dump() and CFlatDB<CMasternodeMan>::Load() methods. Normal CMasternodeMan::CheckAndRemove() overload now has argument of CConnman& type and is used everywhere else. The normal overload has this code in the beginning: if(!masternodeSync.IsMasternodeListSynced()) return; Masternode list is not synced yet when we load "mncache.dat" file, and we save "mncache.dat" file on shutdown, so I presume that it's OK to use overload that does nothing in both cases. Signed-off-by: Oleg Girko <ol@infoserver.lv>
2017-09-19 16:51:38 +02:00
CConnman& connman;
refactor: using reference instead reference to unique_ptr with object (#5381) ## Issue being fixed or feature implemented Many objects created and functions called by passing `const std::unique_ptr<Obj>& obj` instead directly passing `Obj& obj` In some cases it is indeed needed, but in most cases it is just extra complexity that is better to avoid. Motivation: - providing reference to object instead `unique_ptr` is giving warranty that there's no `nullptr` and no need to keep it in mind - value inside unique_ptr by reference can be changed externally and instead `nullptr` it can turn to real object later (or in opposite) - code is shorter but cleaner Based on that this refactoring is useful as it reduces mental load when reading or writing code. `std::unique` should be used ONLY for owning object, but not for passing it everywhere. ## What was done? Replaced most of usages `std::unique_ptr<Obj>& obj` to `Obj& obj`. Btw, in several cases implementation assumes that object can be nullptr and replacement to reference is not possible. Even using raw pointer is not possible, because the empty std::unique_ptr can be initialized later somewhere in code. For example, in `src/init.cpp` there's called `PeerManager::make` and pass unique_ptr to the `node.llmq_ctx` that would be initialized way later. That is out of scope this PR. List of cases, where reference to `std::unique_ptr` stayed as they are: - `std::unique_ptr<LLMQContext>& llmq_ctx` in `PeerManagerImpl`, `PeerManager` and `CDSNotificationInterface` - `std::unique_ptr<CDeterministicMNManager>& dmnman` in `CDSNotificationInterface` Also `CChainState` have 3 references to `unique_ptr` that can't be replaced too: - `std::unique_ptr<llmq::CChainLocksHandler>& m_clhandler;` - `std::unique_ptr<llmq::CInstantSendManager>& m_isman;` - `std::unique_ptr<llmq::CQuorumBlockProcessor>& m_quorum_block_processor;` ## How Has This Been Tested? Run unit/functional tests. ## Breaking Changes No breaking changes, all of these changes - are internal APIs for Dash Core developers only. ## 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 - [x] 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-06-04 22:26:23 +02:00
CMasternodeSync& m_mn_sync;
const std::unique_ptr<CDeterministicMNManager>& dmnman;
CGovernanceManager& govman;
refactor: using reference instead reference to unique_ptr with object (#5381) ## Issue being fixed or feature implemented Many objects created and functions called by passing `const std::unique_ptr<Obj>& obj` instead directly passing `Obj& obj` In some cases it is indeed needed, but in most cases it is just extra complexity that is better to avoid. Motivation: - providing reference to object instead `unique_ptr` is giving warranty that there's no `nullptr` and no need to keep it in mind - value inside unique_ptr by reference can be changed externally and instead `nullptr` it can turn to real object later (or in opposite) - code is shorter but cleaner Based on that this refactoring is useful as it reduces mental load when reading or writing code. `std::unique` should be used ONLY for owning object, but not for passing it everywhere. ## What was done? Replaced most of usages `std::unique_ptr<Obj>& obj` to `Obj& obj`. Btw, in several cases implementation assumes that object can be nullptr and replacement to reference is not possible. Even using raw pointer is not possible, because the empty std::unique_ptr can be initialized later somewhere in code. For example, in `src/init.cpp` there's called `PeerManager::make` and pass unique_ptr to the `node.llmq_ctx` that would be initialized way later. That is out of scope this PR. List of cases, where reference to `std::unique_ptr` stayed as they are: - `std::unique_ptr<LLMQContext>& llmq_ctx` in `PeerManagerImpl`, `PeerManager` and `CDSNotificationInterface` - `std::unique_ptr<CDeterministicMNManager>& dmnman` in `CDSNotificationInterface` Also `CChainState` have 3 references to `unique_ptr` that can't be replaced too: - `std::unique_ptr<llmq::CChainLocksHandler>& m_clhandler;` - `std::unique_ptr<llmq::CInstantSendManager>& m_isman;` - `std::unique_ptr<llmq::CQuorumBlockProcessor>& m_quorum_block_processor;` ## How Has This Been Tested? Run unit/functional tests. ## Breaking Changes No breaking changes, all of these changes - are internal APIs for Dash Core developers only. ## 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 - [x] 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-06-04 22:26:23 +02:00
const std::unique_ptr<LLMQContext>& llmq_ctx;
refactor: subsume CoinJoin objects under CJContext, deglobalize coinJoin{ClientQueueManager,Server} (#5337) ## Motivation CoinJoin's subsystems are initialized by variables and managers that occupy the global context. The _extent_ to which these subsystems entrench themselves into the codebase is difficult to assess and moving them out of the global context forces us to enumerate the subsystems in the codebase that rely on CoinJoin logic and enumerate the order in which components are initialized and destroyed. Keeping this in mind, the scope of this pull request aims to: * Reduce the amount of CoinJoin-specific entities present in the global scope * Make the remaining usage of these entities in the global scope explicit and easily searchable ## Additional Information * The initialization of `CCoinJoinClientQueueManager` is dependent on blocks-only mode being disabled (which can be alternatively interpreted as enabling the relay of transactions). The same applies to `CBlockPolicyEstimator`, which `CCoinJoinClientQueueManager` depends. Therefore, `CCoinJoinClientQueueManager` is only initialized if transaction relaying is enabled and so is its scheduled maintenance task. This can be found by looking at `init.cpp` [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L1681-L1683), [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2253-L2255) and [here](https://github.com/dashpay/dash/blob/93f8df1c31fdce6a14f149acfdff22678c3f22ca/src/init.cpp#L2326-L2327). For this reason, `CBlockPolicyEstimator` is not a member of `CJContext` and its usage is fulfilled by passing it as a reference when initializing the scheduling task. * `CJClientManager` has not used `CConnman` or `CTxMemPool` as `const` as existing code that is outside the scope of this PR would cast away constness, which would be unacceptable. Furthermore, some logical paths are taken that will grind to a halt if they are stored as `const`. Examples of such a call chains would be: * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoinClientSession::DoAutomaticDenominating > CCoinJoinClientSession::StartNewQueue > CConnman::AddPendingMasternode` which modifies `CConnman::vPendingMasternodes`, which is non-const behaviour * `CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoin::IsCollateralValid > AcceptToMemoryPool` which adds a transaction to the memory pool, which is non-const behaviour * There were cppcheck [linter failures](https://github.com/dashpay/dash/pull/5337#issuecomment-1685084688) that seemed to be caused by the usage of `Assert` in `coinjoin/client.h`. This seems to be resolved by backporting [bitcoin#24714](https://github.com/bitcoin/bitcoin/pull/24714). (Thanks @knst!) * Depends on #5546 --------- Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com> Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
2023-09-13 19:52:38 +02:00
const std::unique_ptr<CJContext>& cj_ctx;
};
#endif // BITCOIN_DSNOTIFICATIONINTERFACE_H