Pseudo-Node and putative attack vectors on the network

Question

Pseudo-Node is discussed here on Reddit's /r/Bitcoin

Essentially it functions to relay calls from connected nodes in a random fashion.

This was an experiment into how easily can full nodes be "faked". In conclusion: very easily.

A proof-of-concept implementation (& documentation) is available here:

https://github.com/basil00/PseudoNode

To the network, PseudoNode appears to be a normal full node. It relays invs, txs, blocks, etc. just like a full node. In reality, PseudoNode is a type of p2p proxy server. It merely forwards any request it cannot handle (getdata, getheaders, etc.) to neighboring nodes. For more information see the above links.

PseudoNode uses no disk (no blockchain download required), uses little CPU/RAM, and uses less network resources (bandwidth) than a normal full node. A PseudoNode can "sync" with the network within seconds.

PseudoNode demonstrates some of the problems with incentivized full nodes (including the "Bitnodes Incentive Program"). It is difficult to prove that a full node is really a full node.

The implementation mostly has novelty/proof-of-concept value. It is not intended to be "production" software.

And the FAQ:

Does PseudoNode harm the network?

Short answer: No.

Long answer: Not unless the number of PseudoNodes significantly overwhelms the number of normal full nodes. Otherwise, if PseudoNode can connect to at least some good nodes (default 2), then will PseudoNode will acts just like a normal node and contributes network bandwidth.

Can PseudoNode cause the network to fork?

No, PseudoNode just follows what other nodes are doing.

Can PseudoNode steal coins?

No.

Can PseudoNodes be banned from the network?

Not easily. Requests that PseudoNode cannot handle directly can always be forwarded to other (cooperative) full nodes.

This seems incredibly reckless in terms of attack vectors to me. Obviously a balance between the pros and cons needs assessing, and since its value is "novelty" (self-described by the developer), several cons seem immediately evident:

1. Latency will effectively increase blockchain download times such that new latency = original latency * performance decrease %
2. Nefarious pseudonode could throttle latency to just above the threshold of the nodes enforcing blacklisting (ie throttled latency ~> cutoff latency)
3. An increased percentage of nefarious nodes could possibly execute a Sybil Attack (?)

2 related questions:

1. What other attack vectors (in high-level terms) and their repercussions could be expected from Pseudo-Nodes?
2. Is there any feasible contingencies in the protocol to delineate between a PN and a node? For example, would different Bitcoincore versions identify PNs (or a simple modification to the protocol)?

Answer 1

A large number of interconnected psuedo-nodes makes launching a bandwidth-exhaustion attack much easier. Bitcoin Core validates most information before relaying it, but psuedo-nodes don't validate---so if you can get some psuedo-nodes connected together, it's probably easy to get them to waste tons of bandwidth by relaying junk data to each other and then to their peers.

For example, if there are 101 psuedo-nodes (PNs) connected together, you can send PN1 a valid-looking inv packet announcing a single fake transaction (about 61 bytes plus TCP packet overhead). Each PN relays that inv for a minimum of 6100 wasted upload bytes.

But those PNs are also connected to real nodes. Lets say 500 real nodes, so now the wasted PN upload bandwidth is 36,600 bytes (plus TCP overhead)---all because an attacker created a single 61-byte inv. Worse, the real nodes are going to request the transaction using a 61-byte getdata packet, wasting 30,500 bytes of real node upload bandwidth.

If the attacker sends 1MB of fake data per second for an entire day, he'll use 86 gigabytes of his own bandwidth, but waste 52 terabytes of aggregate PN upload bandwidth and potentially 43 terabytes of real node upload bandwidth.

(Depending on how the PNs are written, they may waste even more bandwidth relaying the getdata packet around.)

Compare this to the cost of running the attack against a single real node. For each 61-byte inv packet the attacker uploads, the real node replies by uploading a single 61-byte getdata. So a bandwidth exhaustion attack against a real node requires roughly a 1:1 about of wasted bandwidth. The real node doesn't further relay the inv until it receives and validates the transaction it refers to, so no other node has any wasted bandwidth.

Is there any feasible contingencies in the protocol to delineate between a PN and a node? For example, would different Bitcoincore versions identify PNs (or a simple modification to the protocol)?

The protocol already has the notion of a DoS ban score, in which each Bitcoin Core node assigns a private score to each of its peers for any bad behavior they perform. Once the DoS ban score for a particular peer reaches a threshold (100 by default), the node disconnects from the peer and refuses further connections from its IP address for a time (one day by default). Bad behaviour includes sending invalid transactions and blocks.

Because PNs don't validate data, they'll happily relay invalid data. If they become common, someone who wants to grief PNs could simply connect to any advertised node and send it a bunch of invalid data. If it was a real full node, it will disconnect (DoS ban). If it was a PN, it would relay that data to real full nodes, causing the real full nodes to DoS ban it. This would make the PN useless and would allow the griefer to detect which nodes are PNs---the griefer could then publish (an unauthenticatable) database of PN IP addresses.

This method works best against long-term PNs. To make it harder to execute short-term Sybil attacks from lots of lightweight PNs, something like Greg Maxwell's proof of storage to make distributed resource consumption costly could be used.