>>15
Simple. Let's say a node is supposed to do the following:
- broadcast itself to other nodes, an initial pooling of which is gathered somehow, but that involves asking other nodes for peers
- accept incoming connections, either from nodes or from outside computers
- forward those connections to other nodes until a limit is hit or the destination is reached or some other constraint
If you can add faulty nodes, you could do something like
- ignore protocol and aggressively seek out every possible node as your initial pool, then reconnect
- to every node in your pool, `forward' a faked connection with a timeout twenty orders of magnitude higher than it should be
- endlessly shuttle messages from one faulty node back to another faulty node, hoping to disrupt as many real nodes as possible while only sacrificing two of your nodes
- when asked for peers, return only fellow faulty nodes, but refuse all incoming connections, hoping to trick the network into creating what it sees as a well-distributed mesh, but is actually a series of bottlenecks
- etc
To some extent, good protocol design will minimize the impact of this, but if you have enough resources you could overwhelm `key' points of the network and defeat byzantine fault tolerance.