pull down to refresh

Notes on 'DoS due to inv-to-send sets growing too large' from May 2023b10c.me/observations/15-inv-to-send-queue/
11.5k sats \ 3 comments \ @0xB10C 22h bitcoin
In October 2024, the Bitcoin Core project disclosed a Denial-of-Service due to inv-to-send sets growing too large, which I authored, for Bitcoin Core versions before v25.0. I have a few notes and screenshots from my investigation back then that I want to persist here.
write
preview
related posts
10 sats \ 2 replies \ @k00b 19h
I'm a little confused about spy node amplification. Why would they have larger sets than normal peers? Is it because they never acknowledge which txs they have, so it's always assumed they have none?
Relevant section:
The effect is amplified by so-called spy nodes which only listen to inv messages and never announce transactions on their own. When a peer announces a transaction to a node, the node can remove it from their m_tx_inventory_to_send set as it’s known by the peer and does not need to be announced anymore. This meant that the sets for spy nodes were even larger and took even more time to sort as they were drained more slowly. Spy nodes, for example, LinkingLion and others, are common and often have multiple connections open to a node in parallel. At times, I count more assumed spy nodes than non-spy node connections to my nodes.
Other than banlists for these nodes, shouldn't we drop connections to nodes that never acknowledge the transactions they've received? Do non-spy nodes do this under some circumstances too?
reply
310 sats \ 1 reply \ @0xB10C OP 16h
Transaction relay between nodes works by announcing (inv msg) that there is a transaction with (w)txid X, the peer requesting X (getdata msg), and us sending X (tx msg).
A spy node only every receives INVs and records where they heard X first. They never request the transaction as they for now only care about the (w)txid.
They also (normally) never INV any transactions to us, as this would mean we don't INV the transaction to them (so giving them less data).
Maybe we can automatically disconnect or ban peers that behave like spy nodes, but there is always the risk that a heuristic is off or a peer behaves like a spy node due to an edge case. For example, a peer might already have all transactions you announce, and doesn't have any to announce to you. This would look like a spy node to use (at least on a shortish time frame, until the peer learns about a tx we don't yet have and can announce to us), but is actually a worthwhile peer to keep.
I'm a little confused about spy node amplification.
Thanks for the feedback. I think I can expand on this in the post a bit. I seem to have assumed that all readers are familiar with transaction relay with spy nodes, which is probably something I should explain.
reply
1 sat \ 0 replies \ @k00b 16h
I read your series about LinkingLion, but the relationship between these tx inventory sets and LinkingLion-like nodes was unclear to me. ie I can imagine that a spy node would produce outlier behavior, but not how exactly.
reply