Ensure we have sufficient transaction-relay peers

sdaftuar commented at 8:06 pm on July 18, 2019: member

Currently, we have no protections in place if our outbound peers are running in -blocksonly mode. In practice, we rely on our outbound peers to be our best source of announced transactions, but if all our outbound peers were -blocksonly, we would make no effort to disconnect any to find an alternative peer to receive transactions from.

We discover at connection time (in the VERSION message) whether our peer will relay transactions on our link. Perhaps we should tolerate some number of -blocksonly peers as outbounds, and once we hit that threshold we should disconnect new blocksonly outbounds?

I suppose another issue could be if it’s worth having logic that tries to determine whether a peer is silently withholding transactions from us… We have logic for blocks, where we try to find a new outbound peer if we haven’t received a new block in a while, but I don’t know if there’s a reasonable way to do this for transactions. My guess is that this is not a very pressing concern, but perhaps we could do something that just tried making new outbound connections if we aren’t receiving any transactions at all?

fanquake added the label P2P on Jul 18, 2019

MarcoFalke added the label Brainstorming on Jul 18, 2019

MarcoFalke commented at 8:27 pm on July 18, 2019: member

I suppose another issue could be if it’s worth having logic that tries to determine whether a peer is silently withholding transactions from us

Are you talking about a peer that sets version.relay to true but behaves like a blocksonly node? I think the time when a node last sent us a tx should help here, it might already be tracked in CNode::nLastTXTime.

If you are talking about a peer that withholds specific transactions, that seems like a separate issue from blocksonly.

MarcoFalke added this to the milestone 0.19.0 on Jul 18, 2019

mzumsande commented at 8:26 pm on July 19, 2019: contributor

If #15759 is merged, would it make sense to attempt to match our designated blocks-only outgoing connections with peers that run in blocks-only mode? It seems ineffective if we have outgoing connections on which we want transactions with peers that don’t offer any, and at the same time have blocks-only outgoing connections with peers that would relay transactions to us if we asked.

sdaftuar commented at 7:05 pm on July 22, 2019: member

If #15759 is merged, would it make sense to attempt to match our designated blocks-only outgoing connections with peers that run in blocks-only mode?

I tend to think that we should not make such an attempt, because I think the goal of our outbound connections (existing plus future blocks-only) is to give us a diverse selection of peers in the hopes that we have at least one honest one. If we preference blocks-only peers for our blocks-only outbounds, then unless there are a lot of similarly diverse blocks-only peers out there, we will reduce our peer diversity substantially.

From an accounting perspective, perhaps there could be a way for us to “downgrade” a link that we expect to be a transaction-relay-peer that turns out to be a blocks-only peer, but I don’t know if it will be worth the trouble of implementing something like that, and it’s not totally clear to me whether that would introduce a bias that would be concerning. I think it’s easiest to reason about pulling a candidate peer out of our addrman at random, connecting, and staying connected as long as it offers the services we expect. In the case of the issue I brought up here, I’d say that we should allow up to 2 or 3 of our outbounds being blocks-only (when we expect them to be tx-relay peers) and then if we encounter further blocks-only outbounds, we disconnect. Anyway, this can all be discussed in any PRs that try to fix this.

sdaftuar commented at 7:09 pm on July 22, 2019: member

Are you talking about a peer that sets version.relay to true but behaves like a blocksonly node? I think the time when a node last sent us a tx should help here, it might already be tracked in CNode::nLastTXTime. @MarcoFalke Yeah that’s what occurred to me when I was thinking about things that could go wrong with transaction relay. I don’t think it’s a big concern, but I guess it’s worth remembering that we have no handling for cases like that.

naumenkogs commented at 6:26 pm on July 23, 2019: member

Having less than 8 transaction relay links leads to information leaks.

I’m talking about the threat model where an attacker runs a number of public nodes and infers sources of transactions based on the timing of incoming messages.

It’s (sort of) difficult now to perform this attack only because diffusion happens simultaneously over different directions. Having less transaction relay links makes diffusion much more inferrable. I don’t have the exact numbers, but I expect it would become really concerning w.r.t. privacy if at least 2/8 outbound connections of every node are blocksonly.

laanwj removed this from the milestone 0.19.0 on Sep 26, 2019

willcl-ark commented at 4:14 pm on September 21, 2023: contributor

This looks related to #28371

Ensure we have sufficient transaction-relay peers #16418