> Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?)
That particular report is essentially "if you send a message with an invalid checksum, the peer just ignores the message and carries on instead of banning you and thereby wastes bandwidth and cpu time".
But this is kind of a pointless report (of a sort all too often produced by paid auditors :( ) -- the same "attacker" can simply send the same messages with a _valid_ checksum at no more cost to them, using the same resources, but totally bypassing the ban. So why bother?
There may be good or bad reasons to disconnect or ban a peer that does something incorrect or unexpected-- depending on the nature of the incorrect action--, but bans that can be evaded by sending one constant instead of another with the same resource usage are not useful protections against denial of service. A downside of this particular ban is that you'll ban hosts that are guilty of the crime of being behind an overactive NAT or idiotic censorware proxy...
[In fact, a lot of the motivation of the checksum is simply to avoid inappropriately banning peers whos messages were invalid simply due to the network corrupting their traffic. Banning on an invalid checksum defeats much of the purpose of the checksum in the first place.]
Bitcoin is moving away from bans more or less completely because of their minimal utility (over otherwise necessary anti-isolation handling) compared to the amount that they amplify the negative effects of simple misconfigration (or even, have themselves resulted in attacks).
The earlier poster's comment about bandwidth usage attacks is probably referring to the fact that no matter what your bitcoin software does a third party can still chew up inbound bandwidth by e.g. sending ICMP echo requests, SYNs, etc.
That particular report is essentially "if you send a message with an invalid checksum, the peer just ignores the message and carries on instead of banning you and thereby wastes bandwidth and cpu time".
But this is kind of a pointless report (of a sort all too often produced by paid auditors :( ) -- the same "attacker" can simply send the same messages with a _valid_ checksum at no more cost to them, using the same resources, but totally bypassing the ban. So why bother?
There may be good or bad reasons to disconnect or ban a peer that does something incorrect or unexpected-- depending on the nature of the incorrect action--, but bans that can be evaded by sending one constant instead of another with the same resource usage are not useful protections against denial of service. A downside of this particular ban is that you'll ban hosts that are guilty of the crime of being behind an overactive NAT or idiotic censorware proxy...
[In fact, a lot of the motivation of the checksum is simply to avoid inappropriately banning peers whos messages were invalid simply due to the network corrupting their traffic. Banning on an invalid checksum defeats much of the purpose of the checksum in the first place.]
Bitcoin is moving away from bans more or less completely because of their minimal utility (over otherwise necessary anti-isolation handling) compared to the amount that they amplify the negative effects of simple misconfigration (or even, have themselves resulted in attacks).
The earlier poster's comment about bandwidth usage attacks is probably referring to the fact that no matter what your bitcoin software does a third party can still chew up inbound bandwidth by e.g. sending ICMP echo requests, SYNs, etc.