Page MenuHomePhabricator

[p2p] Reduce addr blackholes
ClosedPublic

Authored by Fabien on Jan 28 2022, 15:13.

Details

Reviewers
tyler-smith
Group Reviewers
Restricted Project
Maniphest Tasks
Restricted Maniphest Task
Commits
rABCd3a5c3e4328d: [p2p] Reduce addr blackholes
Summary
This PR aims to reduce addr blackholes. When we receive an addr message that contains 10 or less addresses, we forward them to 1-2 peers. This is the main technique we use for self advertisements, so sending to peers that wouldn't relay would effectively "blackhole" the trickle. Although we cannot prevent this in a malicious case, we can improve it for the normal, honest cases, and reduce the overall likelihood of occurrence. Two known cases where peers would not participate in addr relay are if they have connected to you as a block-relay-only connection, or if they are a light client.

This implementation defers initialization of m_addr_known until it is needed, then uses its presence to decide if the peer is participating in addr relay. For outbound (not block-relay-only) peers, we initialize the filter before sending the initial self announcement when processing their version message. For inbound peers, we initialize the filter if/when we get an addr related message (ADDR, ADDRV2, GETADDR). We do NOT initialize the filter based on a SENDADDRV2 message.

Backport of core#21528.

Ref T1696.

Test Plan
ninja all check-all

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Fabien requested review of this revision.Jan 28 2022, 15:13
tyler-smith added a subscriber: tyler-smith.

This makes sense; kind of surprised it didn't work this way before. The implementation and tests look correct. I personally dislike using the presence of m_addr_known this way, but certainly not enough to diverge from the upstream.

This revision is now accepted and ready to land.Jan 28 2022, 17:36
This revision was automatically updated to reflect the committed changes.