8 Commits (f1d807e383942ae20e080174d33ac17afd649351)

Author	SHA1	Message	Date
MarcoFalke	fac23c2114	scripted-diff: Bump copyright headers ... The previous diff touched most files in ./test/, so bump the headers to avoid having to touch them again for a bump later. -BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./test/ -END VERIFY SCRIPT-	3 years ago
John Newbery	2095df7b7b	[addrman] Add Add_() inner function, fix Add() return semantics ... Previously, Add() would return true if the function created a new AddressInfo object, even if that object could not be successfully entered into the new table and was deleted. That would happen if the new table position was already taken and the existing entry could not be removed. Instead, return true if the new AddressInfo object is successfully entered into the new table. This fixes a bug in the "Added %i addresses" log, which would not always accurately log how many addresses had been added. p2p_addrv2_relay.py and p2p_addr_relay.py need to be updated since they were incorrectly asserting on the buggy log (assuming that addresses are added to addrman, when there could in fact be new table position collisions that prevent some of those address records from being added).	3 years ago
Jon Atack	b69a106bcd	test: use test_framework.p2p P2P_SERVICES in functional tests	3 years ago
Pieter Wuille	5648138f59	Randomize the order of addr processing	3 years ago
Pieter Wuille	0d64b8f709	Rate limit the processing of incoming addr messages ... 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.	3 years ago
Vasil Dimov	7593b06bd1	test: ensure I2P addresses are relayed ... This test would fail if `CNetAddr::IsRelayable()` returns `false` for I2P addresses, given that this test node does not have I2P connectivity.	3 years ago
Vasil Dimov	86742811ce	test: use NODE_* constants instead of magic numbers ... We just assigned `NODE_NETWORK | NODE_WITNESS` to `nServices` a few lines above. Use that for verifying correctness instead of `9`.	3 years ago
Vasil Dimov	353a3fdaad	net: advertise support for ADDRv2 via new message ... Introduce a new message `sendaddrv2` to signal support for ADDRv2. Send the new message immediately after sending the `VERACK` message. Add support for receiving and parsing ADDRv2 messages. Send ADDRv2 messages (instead of ADDR) to a peer if he has advertised support for it. Co-authored-by: Carl Dong <contact@carldong.me>	4 years ago