I ran this crawler(https://github.com/virtu/p2p-crawler.git) over the weekend and observed a cluster of 897 nodes that returned a getaddr response of 256 peers. This is way below the usual < 990.
I noticed a bunch of /Satoshi:27.0.0/ nodes on Linode/AS63949 a few weeks ago too. While I didn’t notice the getaddr responses, I noticed that they will disconnect a connection after exactly 30s.
I noticed these nodes last February while trying to find mining pools on the network. They broadcast INVs where some items are duplicated in the INV message, don’t participate in transaction relay (if you relay them a tx), and respond to GETADDR with 256 addresses. My IP address ranges match also. Might need to scroll down in IRC logs, may be extra details there.
15:16 < eugenesiegel> Would anybody know why specifically v27.0 nodes would disconnect inbound connections for not writing after 30 seconds? It doesn't happen with other versions and it happens with quite a few nodes. I didn't see anything in the changelog about any sort of write timeout being changed and I don't see anywhere in the code where a 30 second timeout is
15:16 < eugenesiegel> used. Additionally, if I write a spam message on the connection, the node doesn't disconnect me.
15:34 < sipa> eugenesiegel: and this doesn't happen with 26.0?
15:34 < sipa> also, have you tried 28.0?
15:39 < bitcoin-git> [bitcoin] tdb3 closed pull request #30941: test: simplify timewarp test (master...20240921_simplify_timewarp_tests) https://github.com/bitcoin/bitcoin/pull/30941
15:40 < eugenesiegel> I couldn't reproduce locally when I checked out v27.0. It doesn't happen with remote nodes on 26.0 or 28.0, only nodes on 27.0 from what I can tell. It's also about 800 of these 27.0 nodes
16:13 < lightlike> so they would reject all blocks-only connections they have as inbounds quickly?! is this dependent on v2 transport (BIP324) being used?
16:29 < eugenesiegel> I wrote a light client so it doesn't have v2 transport yet and doesn't do blocks-only connections (so I can't be certain if blocks only connections would be rejected). I can look at the version messages and see if maybe there's a correlation with nServices
16:34 < lightlike> i just mentioned those because with block-relay-only connections (pings every 2 minutes, blocks every 10 minutes, no addr or tx relay) there should be frequent intervals where no messages are exchanged for more than 30s.
17:47 < eugenesiegel> I did a little more digging. Each node offers the exact same service flags of "SFNodeNetwork|SFNodeBloom|SFNodeNetworkLimited|0x800" and they all have the same block height of 882,161
17:48 < eugenesiegel> I think the tip at measurement time was 882,199
17:54 < sipa> 0x800 = NODE_P2P_V2
17:54 < sipa> Weird that they're offering NODE_BLOOM; that's not on in Bitcoin Core by default
18:11 < eugenesiegel> I found the BLOOM weird, the addresses are grouped into about seven /16 blocks
19:36 < sipa> is this linkinglion or some spy?
21:13 < eugenesiegel> I don't think its linkinglion, but I do think they're probably all the same entity. I tested on my mainnet node and v2 handshakes to them fail and are downgraded to v1 handshakes and then fail 30s later. The nodes ignore the sent feefilter and send INV messages always with 50 items and duplicate some of the items in the set. They also have other
21:13 < eugenesiegel> idiosyncrasies like not responding to GETDATA
21:22 < eugenesiegel> They also duplicate hashes _across_ different INVs and waste bandwidth. The main IP ranges are 139.162.0.0/16, 172.104.0.0/16, 172.105.0.0/16, 172.232.0.0/16, 172.233.0.0/16, 172.234.0.0/16, and 172.236.0.0/16 if anybody is curious. I guess I answered my own question about these nodes since this behavior doesn't indicate a normal 27.0 satoshi
21:22 < eugenesiegel> node
21:32 < lightlike> yes, probably not core nodes, but definitely interesting, 800 is not nothing!
--- Log closed Tue Feb 04 00:00:08 2025
11:28 < eugenesiegel> > seeing a few of these connections too with the same characteristics you mention
11:28 < eugenesiegel> They respond to GETADDR and respond with 256 addresses of all of their addresses, so I think all of their nodes are pretty easy to identify. I think it's some sort of tx broadcasting / relay infrastructure
11:29 < eugenesiegel> * 256 of their addresses
