2017-08-09 02:19:06 +02:00
|
|
|
// Copyright (c) 2009-2010 Satoshi Nakamoto
|
2023-04-25 13:51:26 +02:00
|
|
|
// Copyright (c) 2009-2020 The Bitcoin Core developers
|
2017-08-09 02:19:06 +02:00
|
|
|
// Distributed under the MIT software license, see the accompanying
|
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
|
|
|
#ifndef BITCOIN_NET_PROCESSING_H
|
|
|
|
#define BITCOIN_NET_PROCESSING_H
|
|
|
|
|
2022-04-17 12:52:51 +02:00
|
|
|
#include <net.h>
|
2018-09-27 17:18:12 +02:00
|
|
|
#include <sync.h>
|
2022-04-17 12:52:51 +02:00
|
|
|
#include <validationinterface.h>
|
2024-04-09 21:51:13 +02:00
|
|
|
#include <version.h>
|
2022-04-17 12:52:51 +02:00
|
|
|
|
fix: add missing includes and remove obsolete includes (#5562)
## Issue being fixed or feature implemented
Some headers or modules are used objects from STL without including it
directly, it cause compilation failures on some platforms for some
specific compilers such as #5554
## What was done?
Added missing includes and removed obsolete includes for `optional`,
`deque`, `tuple`, `unordered_set`, `unordered_map`, `set` and `atomic`.
Please, note, that this PR doesn't cover all cases, only cases when it
is obviously missing or obviously obsolete.
Also most of changes belongs to to dash specific code; but for cases of
original bitcoin code I keep it untouched, such as missing <map> in
`src/psbt.h`
I used this script to get a list of files/headers which looks suspicious
`./headers-scanner.sh std::optional optional`:
```bash
#!/bin/bash
set -e
function check_includes() {
obj=$1
header=$2
file=$3
used=0
included=0
grep "$obj" "$file" >/dev/null 2>/dev/null && used=1
grep "include <$header>" $file >/dev/null 2>/dev/null && included=1
if [ $used == 1 ] && [ $included == 0 ]
then echo "missing <$header> in $file"
fi
if [ $used == 0 ] && [ $included == 1 ]
then echo "obsolete <$header> in $file"
fi
}
export -f check_includes
obj=$1
header=$2
find src \( -name '*.h' -or -name '*.cpp' -or -name '*.hpp' \) -exec bash -c 'check_includes "$0" "$1" "$2"' "$obj" "$header" {} \;
```
## How Has This Been Tested?
Built code locally
## 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-09-07 16:07:02 +02:00
|
|
|
#include <atomic>
|
|
|
|
|
2024-03-30 01:16:48 +01:00
|
|
|
class CActiveMasternodeManager;
|
2023-02-16 07:34:06 +01:00
|
|
|
class CAddrMan;
|
2022-04-17 12:52:51 +02:00
|
|
|
class CTxMemPool;
|
2024-03-15 16:40:54 +01:00
|
|
|
class CDeterministicMNManager;
|
2024-04-02 14:24:02 +02:00
|
|
|
class CMasternodeMetaMan;
|
|
|
|
class CMasternodeSync;
|
2022-05-05 20:07:00 +02:00
|
|
|
class ChainstateManager;
|
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
|
|
|
class CCoinJoinServer;
|
2024-02-29 15:03:48 +01:00
|
|
|
class CGovernanceManager;
|
2024-04-09 21:51:13 +02:00
|
|
|
class CInv;
|
2024-02-29 15:03:48 +01:00
|
|
|
class CSporkManager;
|
2024-04-09 21:51:13 +02:00
|
|
|
class CTransaction;
|
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;
|
2022-11-07 19:09:44 +01:00
|
|
|
struct LLMQContext;
|
2022-09-22 13:14:48 +02:00
|
|
|
|
2023-04-25 13:51:26 +02:00
|
|
|
extern RecursiveMutex cs_main;
|
|
|
|
extern RecursiveMutex g_cs_orphans;
|
2017-08-09 02:19:06 +02:00
|
|
|
|
2019-09-30 15:34:13 +02:00
|
|
|
/** Default for -maxorphantxsize, maximum size in megabytes the orphan map can grow before entries are removed */
|
|
|
|
static const unsigned int DEFAULT_MAX_ORPHAN_TRANSACTIONS_SIZE = 10; // this allows around 100 TXs of max size (and many more of normal size)
|
2019-09-25 13:03:45 +02:00
|
|
|
/** Default number of orphan+recently-replaced txn to keep around for block reconstruction */
|
|
|
|
static const unsigned int DEFAULT_BLOCK_RECONSTRUCTION_EXTRA_TXN = 100;
|
2021-07-18 06:20:16 +02:00
|
|
|
static const bool DEFAULT_PEERBLOOMFILTERS = true;
|
2021-09-19 06:31:43 +02:00
|
|
|
static const bool DEFAULT_PEERBLOCKFILTERS = false;
|
2020-07-14 08:13:18 +02:00
|
|
|
/** Threshold for marking a node to be discouraged, e.g. disconnected and added to the discouragement filter. */
|
|
|
|
static const int DISCOURAGEMENT_THRESHOLD{100};
|
2020-04-19 13:04:31 +02:00
|
|
|
|
2023-04-27 09:46:47 +02:00
|
|
|
struct CNodeStateStats {
|
|
|
|
int m_misbehavior_score = 0;
|
|
|
|
int nSyncHeight = -1;
|
|
|
|
int nCommonHeight = -1;
|
2024-03-24 09:03:34 +01:00
|
|
|
int m_starting_height = -1;
|
2024-04-03 18:10:14 +02:00
|
|
|
std::chrono::microseconds m_ping_wait;
|
2023-04-27 09:46:47 +02:00
|
|
|
std::vector<int> vHeightInFlight;
|
2024-04-25 13:52:57 +02:00
|
|
|
bool m_relay_txs;
|
2024-04-12 18:40:58 +02:00
|
|
|
uint64_t m_addr_processed = 0;
|
|
|
|
uint64_t m_addr_rate_limited = 0;
|
2024-04-12 18:34:32 +02:00
|
|
|
bool m_addr_relay_enabled{false};
|
2023-04-27 09:46:47 +02:00
|
|
|
};
|
|
|
|
|
2023-04-28 07:23:04 +02:00
|
|
|
class PeerManager : public CValidationInterface, public NetEventsInterface
|
|
|
|
{
|
2017-08-09 02:19:06 +02:00
|
|
|
public:
|
2023-04-28 07:23:04 +02:00
|
|
|
static std::unique_ptr<PeerManager> make(const CChainParams& chainparams, CConnman& connman, CAddrMan& addrman,
|
|
|
|
BanMan* banman, CScheduler &scheduler, ChainstateManager& chainman,
|
2024-04-02 14:24:02 +02:00
|
|
|
CTxMemPool& pool, CMasternodeMetaMan& mn_metaman, CMasternodeSync& mn_sync,
|
|
|
|
CGovernanceManager& govman, CSporkManager& sporkman,
|
2024-03-30 01:16:48 +01:00
|
|
|
const CActiveMasternodeManager* const mn_activeman,
|
2024-03-15 16:40:54 +01:00
|
|
|
const std::unique_ptr<CDeterministicMNManager>& dmnman,
|
2024-02-29 15:03:48 +01:00
|
|
|
const std::unique_ptr<CJContext>& cj_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<LLMQContext>& llmq_ctx, bool ignore_incoming_txs);
|
2023-04-28 07:23:04 +02:00
|
|
|
virtual ~PeerManager() { }
|
2017-11-02 20:13:17 +01:00
|
|
|
|
2023-04-27 09:46:47 +02:00
|
|
|
/** Get statistics from node state */
|
2021-04-21 07:20:35 +02:00
|
|
|
virtual bool GetNodeStateStats(NodeId nodeid, CNodeStateStats& stats) const = 0;
|
2023-04-28 08:36:19 +02:00
|
|
|
|
2023-04-27 09:21:41 +02:00
|
|
|
/** Whether this node ignores txs received over p2p. */
|
2023-04-28 07:23:04 +02:00
|
|
|
virtual bool IgnoresIncomingTxs() = 0;
|
2023-04-27 09:46:47 +02:00
|
|
|
|
2024-03-19 10:23:52 +01:00
|
|
|
/** Send ping message to all peers */
|
|
|
|
virtual void SendPings() = 0;
|
|
|
|
|
2024-04-25 13:52:57 +02:00
|
|
|
/** Is an inventory in the known inventory filter. Used by InstantSend. */
|
|
|
|
virtual bool IsInvInFilter(NodeId nodeid, const uint256& hash) const = 0;
|
|
|
|
|
|
|
|
/** Broadcast inventory message to a specific peer. */
|
|
|
|
virtual void PushInventory(NodeId nodeid, const CInv& inv) = 0;
|
|
|
|
|
2024-04-09 21:51:13 +02:00
|
|
|
/** Relay inventories to all peers */
|
|
|
|
virtual void RelayInv(CInv &inv, const int minProtoVersion = MIN_PEER_PROTO_VERSION) = 0;
|
|
|
|
virtual void RelayInvFiltered(CInv &inv, const CTransaction &relatedTx,
|
|
|
|
const int minProtoVersion = MIN_PEER_PROTO_VERSION) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This overload will not update node filters, use it only for the cases
|
|
|
|
* when other messages will update related transaction data in filters
|
|
|
|
*/
|
|
|
|
virtual void RelayInvFiltered(CInv &inv, const uint256 &relatedTxHash,
|
|
|
|
const int minProtoVersion = MIN_PEER_PROTO_VERSION) = 0;
|
|
|
|
|
2021-03-18 07:25:27 +01:00
|
|
|
/** Relay transaction to all peers. */
|
|
|
|
virtual void RelayTransaction(const uint256& txid)
|
|
|
|
EXCLUSIVE_LOCKS_REQUIRED(cs_main) = 0;
|
|
|
|
|
2023-04-28 07:23:04 +02:00
|
|
|
/** Set the best height */
|
|
|
|
virtual void SetBestHeight(int height) = 0;
|
2023-04-27 09:46:47 +02:00
|
|
|
|
2023-04-28 07:17:42 +02:00
|
|
|
/**
|
2020-07-14 08:13:18 +02:00
|
|
|
* Increment peer's misbehavior score. If the new value surpasses DISCOURAGEMENT_THRESHOLD (specified on startup or by default), mark node to be discouraged, meaning the peer might be disconnected & added to the discouragement filter.
|
2023-04-28 07:17:42 +02:00
|
|
|
*/
|
2023-04-28 07:23:04 +02:00
|
|
|
virtual void Misbehaving(const NodeId pnode, const int howmuch, const std::string& message = "") = 0;
|
2023-04-28 07:17:42 +02:00
|
|
|
|
|
|
|
/**
|
2023-04-28 07:23:04 +02:00
|
|
|
* Evict extra outbound peers. If we think our tip may be stale, connect to an extra outbound.
|
|
|
|
* Public for unit testing.
|
2023-04-28 07:17:42 +02:00
|
|
|
*/
|
2020-09-08 22:13:32 +02:00
|
|
|
virtual void CheckForStaleTipAndEvictPeers() = 0;
|
2023-04-28 07:17:42 +02:00
|
|
|
|
2023-04-28 07:23:04 +02:00
|
|
|
/** Process a single message from a peer. Public for fuzz testing */
|
|
|
|
virtual void ProcessMessage(CNode& pfrom, const std::string& msg_type, CDataStream& vRecv,
|
2020-07-10 16:06:11 +02:00
|
|
|
const std::chrono::microseconds time_received, const std::atomic<bool>& interruptMsgProc) = 0;
|
2023-04-27 09:21:41 +02:00
|
|
|
|
2023-04-28 07:23:04 +02:00
|
|
|
virtual bool IsBanned(NodeId pnode) = 0;
|
Merge #19858: Periodically make block-relay connections and sync headers
b3a515c0bec97633a76bec101af47c3c90c0b749 Clarify comments around outbound peer eviction (Suhas Daftuar)
daffaf03fbede6c01287779e464379ee3acb005a Periodically make block-relay connections and sync headers (Suhas Daftuar)
3cc8a7a0f5fa183cd7f0cf5e56f16f9a9d1f2441 Use conn_type to identify block-relay peers, rather than m_tx_relay == nullptr (Suhas Daftuar)
91d61952a82af3e8887e8ae532ecc19d87fe9073 Simplify and clarify extra outbound peer counting (Suhas Daftuar)
Pull request description:
To make eclipse attacks more difficult, regularly initiate outbound connections
and stay connected long enough to sync headers and potentially learn of new
blocks. If we learn a new block, rotate out an existing block-relay peer in
favor of the new peer.
This augments the existing outbound peer rotation that exists -- currently we
make new full-relay connections when our tip is stale, which we disconnect
after waiting a small time to see if we learn a new block. As block-relay
connections use minimal bandwidth, we can make these connections regularly and
not just when our tip is stale.
Like feeler connections, these connections are not aggressive; whenever our
timer fires (once every 5 minutes on average), we'll try to initiate a new
block-relay connection as described, but if we fail to connect we just wait for
our timer to fire again before repeating with a new peer.
ACKs for top commit:
ariard:
Code Review ACK b3a515c, only change since last time is dropping a useless `cs_main` taking. I manually tested a previous version of the PR, and not substantial change has been introduced since then which would alter behavior IMO.
jonatack:
Tested ACK b3a515c0bec97633a76bec101af47c3c90c0b749 over several weeks, though this change and behavior could benefit from test coverage and other follow-ups (refactoring, etc.) described in the review feedback. I did not verify the behavior of `m_start_extra_block_relay_peers` only being enabled after initial chain sync. Since my last review, one unneeded `cs_main` lock was removed.
Tree-SHA512: 75fc6f8e8003e88e93f86b845caf2d30b8b9c0dbb0a6b8aabe4e24ea4f6327351f736a068a3b2720a8a581b789942a3a47f921e2afdb47e88bc50d078aa37b6f
2020-12-11 10:19:44 +01:00
|
|
|
|
|
|
|
/** Whether we've completed initial sync yet, for determining when to turn
|
|
|
|
* on extra block-relay-only peers. */
|
|
|
|
bool m_initial_sync_finished{false};
|
|
|
|
|
2017-08-09 02:19:06 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
#endif // BITCOIN_NET_PROCESSING_H
|