DoS countermeasures may facilitate network fragmentation attacks

[ByteCoin]

An attacker concocts two different sequences of blocks and/or transactions and/or other messages and injects them into the network at two points. Clients readily adopt and incorporate either one of the two sequences but, having adopted one they reject the other. Moreover,  the sequences are engineered so that the clients in possession of one sequence think that clients in possession of the other sequence are DoS attacking them. The DoS countermeasures then ensure that the two client groups ban each other. The situation is now ripe for a double-spend attack.

This conceptual attack is possible on the current network if a sequence could be found which would prevent the adoption of received valid blocks. It seems difficult to prove that no such sequences can exist. The DoS countermeasures might make an attack easier because clients will not accept valid blocks from a banned peer.

I therefore suggest that new block headers should always be accepted even from banned peers. If the hash is correct and of the required difficulty then the block should also be obtained from the peer.

A DoS attack which requires spamming targets with hashes of high difficulty would be ridiculously costly and if a client received such a stream then it could probably take it as a hint that it was on a small network fragment which had just reconnected or that SHA256 had been broken etc... Some action would be required other than just banning the peer and carrying on as normal.

Also, code which detects a substantial apparent loss of hashing power and prevents transactions from going confirmed should be developed and deployed in tandem with the DoS countermeasures code.

ByteCoin

[1501023123]

1501023123

[1501023123]

1501023123

[1501023123]

1501023123

[1501023123]

1501023123

[1501023123]

1501023123

[etotheipi]

Btw, you get a very similar vulnerability through timejacking (aka "forcing clock drift").  It's in the highest class of vulnerability according to the Bitcoin weaknesses page.  It does almost exactly what you propose, by forcing the node's clock to be more then 2 hours out of sync, it will reject a perfectly valid block while the rest of the network continues normally.  Since the rest of the network is building off that block, the victim node will not see any new blocks except for "poisoned blocks" sent by the attacker (who needs a bit of computing power to produce them, but nowhere near 50%).

I agree, nodes should "respect" block headers with the correct proof-of-work regardless of who sent them.  Although, this wouldn't benefit a victim of timejacking, I can't think of why it would be bad to accept them.

As for your last point, how does a node actually determine network speed?  Is it averaged over a certain number of previous block timestamps?  If it can measure this reliably and without too much latency, then this could be a very reliable indicator of something abnormal occurring.  In addition to targeted attacks like you suggest, if someone tried to DoS the main mining pools in an effort to boost their own computing power past 50%, there would be a similar drop in global computation speed and the client would go into some sort of safe-mode.

[ByteCoin]

You get a very similar vulnerability through timejacking (aka "forcing clock drift"). 

Thanks for that!

My first thought for timejacking is that non-miners have no business having an opinion on what time it is. They should just follow the longest chain. If they choose to start rejecting blocks because they disagree with the time, they should then notice that the apparent hashrate has fallen and freeze. This limits the damage.
With miners, the decision to reject a block based on time is similar to the decision to reject a block because it doesn't clear up enough outstanding transactions, cartel enforcement etc..

ByteCoin

[Gavin Andresen]

I like the idea of trying to prove that the DoS code doesn't increase the chance of network fragmentation.

The DoS countermeasures should be careful not to penalize or ban peers for any messages that the client will (or might, in another situation) relay.

For example, double-spent transactions don't trigger the DoS countermeasure code.

That should be sufficient to prevent split-the-network attacks; if an attacker wants to try to split the network, the only way the attacker would be successful is if it could somehow send messages to peers that ARE relayed and trigger disconnections elsewhere in the network.

Looking through the patch:
  https://github.com/bitcoin/bitcoin/pull/517/files

... I see a couple of cases where relayed messages are penalized (block times too far off, and hitting the free transaction relay limit).  To be safe, I'll remove them.

As for relaying block headers for banned peers:  "banned" means "if you try to connect to me I'll simply drop the connection attempt." I feel strongly that is the correct behavior; the motivation for the DoS prevention code is to "whitelist" peer behavior, and try to prevent possible 0-day attacks like "if I send you THIS invalid transactions followed by THAT sequence of weird bytes followed by THIS corrupted block header THEN I trigger an obscure bug in the version of OpenSSL that you're running and compromise your machine...."