Ban "invalid messagestart" nodes #9900

If connecting node is not sending proper "messagestart" it should be banned. There is a lot cpu/bandwidth wasted because those "fake" nodes trying to connect over and over. Grep debug.log for "PROCESSMESSAGE: INVALID MESSAGESTART 44version" to see how much it is. After this patch node is dropped instantly.

utACK 82573cb Those "fake nodes" are likely just altcoin nodes. They don't want to be in the same network either.

I'd be surprised if you are spending a significant amount of CPU/bandwidth on such nodes. This patch doesn't stop them from connecting (only disconnects directly thereafter), so it won't lower the CPU cost much, either. Do you have any idea what the nodes are who are doing this? I have never seen this except for one specific case of a misconfigured testnet node.

On March 1, 2017 4:33:11 PM EST, Rav3nPL notifications@github.com wrote:

If connecting node is not sending proper "messagestart" it should be banned. There is a lot cpu/bandwidth wasted because those "fake" nodes trying to connect over and over. Grep debug.log for "PROCESSMESSAGE: INVALID MESSAGESTART 44version" to see how much it is. After this patch node is dropped instantly. You can view, comment on, or merge this pull request online at:

#9900

-- Commit Summary --

• Ban "invalid messagestart" nodes

-- File Changes --

M src/net_processing.cpp (1)

-- Patch Links --

https://github.com/bitcoin/bitcoin/pull/9900.patch https://github.com/bitcoin/bitcoin/pull/9900.diff

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9900

NACK. This would prohibit a few reasonable-ish protocol changes in the future, for little gain.

As for now those "bad altcions" nodes keep our daemon busy for no reason - it have to accept connection, receive some handshake data and parse response. Then daemon decide to drop connection, but do nothing more, so node is back in few seconds trying again, again, again. Because they are on totally different blockchain if we allow to connect there can be a lot more resources wasted network-wide. After this patch "bad" node is banned, so incoming connection is dropped instantly by IP. After I run it on my node I see in log, that those "bad" nodes are trying to connect every few seconds.

There are hardly any more system resources wasted disconnecting after receiving the initial bad header than disconnecting before then. It really shouldn't matter almost at all.

On March 2, 2017 2:42:12 AM EST, Rav3nPL notifications@github.com wrote:

As for now those "bad altcions" nodes keep our daemon busy for no reason - it have to accept connection, receive some handshake data and parse response. Then daemon decide to drop connection, but do nothing more, so node is back in few seconds trying again, again, again. Because they are on totally different blockchain if we allow to connect there can be a lot more resources wasted network-wide. After this patch "bad" node is banned, so incoming connection is dropped instantly by IP. After I run it on my node I see in log, that those "bad" nodes are trying to connect every few seconds.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9900#issuecomment-283579975

Banning is supposed to be used when nodes waste resources. Sending invalid/incomprehensible data just warrants a disconnect.

Possibly the solution here is to change the log level for connections from nodes which produce gibberish?

Bluematt's comments were my initial thought. I think @pstratem 's suggestion is good... most of the resources being wasted here is the log entry. :) Invalid messagestarts happen any time a non-bitcoin protocol connects, its not interesting.

Agree with changing the logging for those messages. They shouldn't be shown at all unless net debugging is enabled.

Closing this - it's clearly not the direction we want to go in.