Why do nodes ignore the relay=false in version and send MSG_TX inv?

[Coding Enthusiast]

It is my understanding that when the relay (the last byte of a version message) is set to 0 (false) the other node is supposed to not send any inv messages containing transactions but they seem to ignore this and at the very beginning of the connection (after handshake) start sending inv messages of type MSG_TX.
Why is that?

Haven't tried all but from those that tested so far: new bitcoin core versions (0.20.1 and 0.18.0) are like this while old ones (0.12.1) aren't. In other words the new versions seem to not respect the relay flag anymore.

[1715469989]

1715469989

[1715469989]

1715469989

[1715469989]

1715469989

[1715469989]

1715469989

[1715469989]

1715469989

[gmaxwell]

You're either sending the flag wrong, you're sending a mempool message, or you're getting confused by fake nodes again.

Neither of my block-relay-only peers have any invs sent or received, and sending tx invs is unambiguously gated on the relay flag in the code.

[Coding Enthusiast]

You're either sending the flag wrong,

That is not possible.

you're sending a mempool message,

The only messages I send are: version, verack, sendheaders, ping.
Anything else that would change relay such as filters depend on my flag to be true so they aren't sent. I also don't have any code for a mempool message.

or you're getting confused by fake nodes again.

I have to investigate this but the nodes seem to be real and capable of supplying me with headers which is where I am.

Let me dig the DNS seeds and come back to you on that.
Update: I can't reproduce this on any of the IP addresses I get from DNS seeds!

[gmaxwell]

I checked my last week of logs and don't see any "inv sent in violation of protocol", which is what gets logged if a relay=false peer sends an inv.

[Coding Enthusiast]

I checked my last week of logs and don't see any "inv sent in violation of protocol", which is what gets logged if a relay=false peer sends an inv.

Thanks for checking. Here is an example IP that is violating it: 13.124.88.142:8333
None of the IP addresses I got from DNS seeds had this issue though. Fake user agent maybe?

[DaveF]

Looking up that IP it goes to an AWS server in the Asia Pacific area:

Amazon Technologies Inc. AT-88-Z (NET-13-124-0-0-1) 13.124.0.0 - 13.127.255.255
AWS Asia Pacific (Seoul) Region AMAZON-ICN (NET-13-124-0-0-2) 13.124.0.0 - 13.124.255.255

Checking a bit more it's on the firehol blacklist:

https://github.com/firehol/
https://github.com/firehol/blocklist-ipsets/blob/master/bitcoin_nodes_1d.ipset

No idea if it's been on that list for a while or got added because of this thread.
You would have to go back and take a look.

-Dave

[Coding Enthusiast]

Checking a bit more it's on the firehol blacklist:
https://github.com/firehol/blocklist-ipsets/blob/master/bitcoin_nodes_1d.ipset

This list seems to be simply calling the bitnodes.io API to fetch all the IP addresses they have. It doesn't look like a blacklist though.

[gmaxwell]

It wasn't on my blacklist but that isn't too surprising, that behaviour causes bitcoin core to instantly disconnect for a little while now-- so if I ever connected to it I probably didn't stay connected long enough to notice its other misbehaviour.