Sync with the main repo #12

boost::thread_group usage was removed in #21016.

* When accepting an I2P connection, assume the peer has port 0 instead of the default 8333 (for mainnet). It is not being sent to us, so we must assume something. * When deriving our own I2P listen CService use port 0 instead of the default 8333 (for mainnet). So that we later advertise it to peers with port 0. In the I2P protocol SAM 3.1 and older (we use 3.1) ports are not used, so they are irrelevant. However in SAM 3.2 and newer ports are used and from the point of view of SAM 3.2, a peer using SAM 3.1 seems to have specified port=0.

Change `CChainParams::GetDefaultPort()` to return 0 if the network is I2P.

When connecting to an I2P host we don't specify destination port and it is being forced to 0 by the SAM 3.1 proxy, so if we connect to the same host on two different ports, that would be actually two connections to the same service (listening on port 0). Fixes bitcoin/bitcoin#21389

This is a temporary change to convert I2P addresses that have propagated with port 8333 to ones with port 0. It would cause a problem some day if indeed some bitcoin software is listening on port 8333 only and rejects connections to port 0 and we are still using SAM 3.1 which only supports port 0. In this case we would replace 8333 with 0 and try to connect to such nodes. This commit should be included in 22.0 and be reverted before 23.0 is released.

Co-authored-by: Jon Atack <jon@atack.com>

Can be reviewed with --ignore-all-space

in my testing from 45-55 seconds to 15.

This is more visible than a comment hidden in an RPC helper function.

The helper was previously unused. This commit changes it to be more meaningful and puts it to use. See previous discussion at https://github.com/bitcoin/bitcoin/pull/19438/files#r650687320

Since we now have multiple chainstate objects, only one of them is active at any given time. An active chainstate has a mempool, but there's no point to others having one. This change will simplify proposed assumeutxo semantics. See the discussion here: bitcoin/bitcoin#15606 (review) Co-authored-by: Russell Yanofsky <russ@yanofsky.org>

Allows fewer arguments and simplification of call sites. Co-authored-by: John Newbery <john@johnnewbery.com>

Unnecessary argument since we can make use of this->m_mempool Co-authored-by: John Newbery <john@johnnewbery.com>

Makes sense and saves on arguments. Co-authored-by: John Newbery <john@johnnewbery.com>

Co-authored-by: Vasil Dimov <vd@FreeBSD.org>

in ProtectEvictionCandidatesByRatio(). Thank you to Vasil Dimov, whose suggestions during a post-merge discussion about PR 21261 reminded me that I had done this in earlier versions of the PR, e.g. commits like ef411cd2. Co-authored-by: Vasil Dimov <vd@FreeBSD.org>

for the usual case when some of the protected networks don't have eviction candidates, to reduce the number of iterations in ProtectEvictionCandidatesByRatio(). Picks up an idea in ef411cd2 that I had dropped.

in ProtectEvictionCandidatesByRatio(). With this change, `if (n.count == 0) continue;` will be true if a network had candidates protected in the first iterations and has no candidates remaining to be protected in later iterations. Co-authored-by: Jon Atack <jon@atack.com>

Document how to update settings on and for the transifex website before and after branch-off of a new release.

These have been integrated into the script long ago.

Nodes that can reach the I2P network (have set `-i2psam=`) will relay I2P addresses even without this patch. However, nodes that can't reach the I2P network will not. This was done as a precaution in bitcoin/bitcoin#20119 before anybody could connect to I2P because then, for sure, it would have been useless. Now, however, we have I2P support and a bunch of I2P nodes, so get all nodes on the network to relay I2P addresses to help with propagation, similarly to what we do with Tor addresses.

We just assigned `NODE_NETWORK | NODE_WITNESS` to `nServices` a few lines above. Use that for verifying correctness instead of `9`.

This way we can compare CAddress objects using `==` or even arrays of CAddress using `array1 == array2`.

This test would fail if `CNetAddr::IsRelayable()` returns `false` for I2P addresses, given that this test node does not have I2P connectivity.

.PHONY does not take patterns (such as print-%) as prerequisites. Have print-% depend on FORCE and mark FORCE as phony. $ # on master $ make print-host host=x86_64-pc-linux-gnu $ touch print-host $ make print-host make: 'print-host' is up to date. $ $ git co mark_print_as_phony Switched to branch 'mark_print_as_phony' $ make print-host host=x86_64-pc-linux-gnu $ touch FORCE $ make print-host host=x86_64-pc-linux-gnu

It is no longer required after switching to Qt top-level build.

Qt lrelease tool depends on the xml module. This change guarantees that it is always available after being bootstrapped.

If a ScriptPubKeyMan does not implement Upgrade, then using upgraewallet will fail unexpectedly. By changing the default to return true, then this error can be avoided. This is still correct because a successful upgrade can be that nothing happened.

Moved implementations of `ConsumeTxMemPoolEntry`, `ContainsSpentInput`, `ConsumeNetAddr`, and the methods(open, read, write, seek, close) of FuzzedFileProvider from test/fuzz/util.h to test/fuzz/util.cpp.

While limitations on the influence of attackers on addrman already exist (affected buckets are restricted to a subset based on incoming IP / network group), there is no reason to permit them to let them feed us addresses at more than a multiple of the normal network rate. This commit introduces a "token bucket" rate limiter for the processing of addresses in incoming ADDR and ADDRV2 messages. Every connection gets an associated token bucket. Processing an address in an ADDR or ADDRV2 message from non-whitelisted peers consumes a token from the bucket. If the bucket is empty, the address is ignored (it is not forwarded or processed). The token counter increases at a rate of 0.1 tokens per second, and will accrue up to a maximum of 1000 tokens (the maximum we accept in a single ADDR or ADDRV2). When a GETADDR is sent to a peer, it immediately gets 1000 additional tokens, as we actively desire many addresses from such peers (this may temporarily cause the token count to exceed 1000). The rate limit of 0.1 addr/s was chosen based on observation of honest nodes on the network. Activity in general from most nodes is either 0, or up to a maximum around 0.025 addr/s for recent Bitcoin Core nodes. A few (self-identified, through subver) crawler nodes occasionally exceed 0.1 addr/s.

Includes logging improvements by Vasil Dimov and John Newbery.

Negative `nNew` or `nTried` are not possible during normal operation. So, if we read such values during unserialize, report addrman corruption. Fixes bitcoin/bitcoin#22450

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sync with the main repo #12

Sync with the main repo #12

Commits on Jul 19, 2021