dash/src/net_processing.h

86 lines
3.4 KiB
C
Raw Normal View History

// Copyright (c) 2009-2010 Satoshi Nakamoto
// Copyright (c) 2009-2020 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_NET_PROCESSING_H
#define BITCOIN_NET_PROCESSING_H
#include <net.h>
#include <sync.h>
#include <validationinterface.h>
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>
class CAddrMan;
class CTxMemPool;
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;
struct CJContext;
struct LLMQContext;
class CGovernanceManager;
extern RecursiveMutex cs_main;
extern RecursiveMutex g_cs_orphans;
/** 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)
/** Default number of orphan+recently-replaced txn to keep around for block reconstruction */
static const unsigned int DEFAULT_BLOCK_RECONSTRUCTION_EXTRA_TXN = 100;
static const bool DEFAULT_PEERBLOOMFILTERS = true;
static const bool DEFAULT_PEERBLOCKFILTERS = false;
Merge bitcoin#13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications (#3414) * Merge #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications 87fe292d897e09e176ac7e254144466c319cc9ac doc: Mention disabling BIP61 in bips.md (Wladimir J. van der Laan) fe16dd8226d924f44432c5b5014aa49ff45c82ff net: Add option `-enablebip61` to configure sending of BIP61 notifications (Wladimir J. van der Laan) Pull request description: This commit adds a boolean option `-peersendreject`, defaulting to `1`, that can be used to disable the sending of [BIP61](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki) `reject` messages. This functionality has been requested for various reasons: - security (DoS): reject messages can reveal internal state that can be used to target certain resources such as the mempool more easily. - bandwidth: a typical node sends lots of reject messages; this counts against upstream bandwidth. Also the reject messages tend to be larger than the message that was rejected. On the other hand, reject messages can be useful while developing client software (I found them indispensable while creating bitcoin-submittx), as well as for our own test cases, so whatever the default becomes on the long run, IMO the functionality should be retained as option. But that's a discussion for later, for now it's simply a node operator decision. Also adds a RPC test that checks the functionality. Tree-SHA512: 9488cc53e13cd8e5c6f8eb472a44309572673405c1d1438c3488f627fae622c95e2198bde5ed7d29e56b948e2918bf1920239e9f865889f4c37c097c37a4d7a9 * 0.17 -> 0.16 Signed-off-by: Pasta <pasta@dashboost.org> * tx1 -> base_ tx fixing 13134 Signed-off-by: Pasta <pasta@dashboost.org> * move added bip61 message checking up Signed-off-by: Pasta <pasta@dashboost.org> * Dash specific code, only send reject messages if bip61 is enabled Signed-off-by: Pasta <pasta@dashboost.org> * Fix invalidtxrequest.py Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com> Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2020-04-19 13:04:31 +02:00
struct CNodeStateStats {
int m_misbehavior_score = 0;
int nSyncHeight = -1;
int nCommonHeight = -1;
std::vector<int> vHeightInFlight;
};
class PeerManager : public CValidationInterface, public NetEventsInterface
{
public:
static std::unique_ptr<PeerManager> make(const CChainParams& chainparams, CConnman& connman, CAddrMan& addrman,
BanMan* banman, CScheduler &scheduler, ChainstateManager& chainman,
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
CTxMemPool& pool, CGovernanceManager& govman, const std::unique_ptr<CJContext>& cj_ctx,
const std::unique_ptr<LLMQContext>& llmq_ctx, bool ignore_incoming_txs);
virtual ~PeerManager() { }
/** Get statistics from node state */
virtual bool GetNodeStateStats(NodeId nodeid, CNodeStateStats& stats) = 0;
/** Whether this node ignores txs received over p2p. */
virtual bool IgnoresIncomingTxs() = 0;
/** Relay transaction to all peers. */
virtual void RelayTransaction(const uint256& txid)
EXCLUSIVE_LOCKS_REQUIRED(cs_main) = 0;
/** Set the best height */
virtual void SetBestHeight(int height) = 0;
/**
* Increment peer's misbehavior score. If the new value surpasses banscore (specified on startup or by default), mark node to be discouraged, meaning the peer might be disconnected & added to the discouragement filter.
*/
virtual void Misbehaving(const NodeId pnode, const int howmuch, const std::string& message = "") = 0;
/**
* Evict extra outbound peers. If we think our tip may be stale, connect to an extra outbound.
* Public for unit testing.
*/
virtual void CheckForStaleTipAndEvictPeers() = 0;
/** Process a single message from a peer. Public for fuzz testing */
virtual void ProcessMessage(CNode& pfrom, const std::string& msg_type, CDataStream& vRecv,
const std::chrono::microseconds time_received, const std::atomic<bool>& interruptMsgProc) = 0;
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};
};
#endif // BITCOIN_NET_PROCESSING_H