Ignore alert messages that fail signature verification. #5179

Fixes #5160

For non-Bitcoin Core nodes, they should know that relaying alerts to a /Satoshi/ node that are not signed by the /Satoshi/ key will be rejected, so should probably just relay based on the version field. Still, no objection if the point is to not ban after alert-key-rotate.

Actually, I take that back, even satoshi clients should just relay based on the version the other peer gives them, in the case of an alert key change.

I'm slightly against this.

There is a theoretical DoS attack possible; it might be possible to keep a node with high bandwidth but not much CPU busy doing nothing but validating invalid alert signatures (CPU exhaustion attack). Banning after getting 10 invalid-signature-alerts prevents that.

Mostly not a practical attack, most nodes are bandwidth-constrained not CPU-constrained. But I could imagine attacking a VPS running in a datacenter from another machine in the same datacenter.

In any case, if others think this should be done then there should be a regression test to make sure bitcoind doesn't behave badly if it gets a bunch of zero-size alerts with bad signatures, max-message-size-alerts with bad signatures, etc.....

Sigantures use a variable length encoding. ignoring the alert format and just thinking about signatures lone, I expect you could hard saturate the cpu on an arbtirary host with about 1-2 mbit/sec of bogus signatures.

If we want the alert messages to be usable by other clients without us banning them, can't we add a 'client type' marker?

If that doesn't match 'Satoshi', don't even check the signature just ignore it. If we DO have to verify the signature and it fails, give the penalty, that avoids the DoS angle. We only want to punish fake bitcoin core alerts.

Other clients can then sent alert messages at will, with their own marker, and we'll ignore the messages without eventually banning them.

@laanwj that doesn't really help, because you cannot get connectivity that way, you'll end up partitioned and not getting the messages. If you're going to implement a seperate topology to avoid this, you don't even need to use alerts, just use another message type and it will be ignored.

Well achieving connectivity is up to them. The only thing it'd achieve is to make the alert message usable by other clients and remove the 'satoshi preference' from the protocol.

Agree that using another message type would work just as well though!

Anyhow - closing this, as it opens up to a DoS angle without any gain. I like @gmaxwell's idea: just use a different message instead of sending alert with your own signature, making bitcoin core clients unnecessarily validate signatures.

Ideally alert should then have been alert_satoshi (or have a client name field) as it only applies to us but there's no turning back...