0

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)?
  • When you ask about psuedo nodes, are you asking about this specific piece of software, or the general idea of modifying the Bitcoin client? When you say, This seems incredibly reckless in terms of attack vectors, do you mean that pseudo nodes would be vulnerable to attacks that the Bitcoin client isn't, or that the author hasn't thought of all of the attacks that could be carried out? – Nick ODell Feb 15 '15 at 1:02
  • @NickODell I'm framing this more in light of the open source code being released which basically nullifies the development time that would normally hinder nefarious parties from pursuing this. I should also clarify, have there been past instances of pseudonodes? Or is this not a new issue? – Wizard Of Ozzie Feb 15 '15 at 1:05
  • @WizardOfOzzie All of the "attacks" 1..3 are possible with normal full nodes. – Basil Feb 17 '15 at 3:11
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.

  • Thank you for the detailed theory; I've amended my query to ascertain what, if anything, could delineate between a PN and a node (eg where does the protocol compensate for these scenarios. – Wizard Of Ozzie Feb 15 '15 at 16:16
  • @WizardOfOzzie edited to answer the second part of your question. – David A. Harding Feb 15 '15 at 17:30
  • Fantastic, that makes a lot of sense. Good to know this isn't a major issue. I'm awarding you to bounty I'm setting up when I can do so – Wizard Of Ozzie Feb 15 '15 at 18:01
  • @DavidA.Harding By default a PN will not relay data unless at least 2 other randomly selected nodes are also relaying the same data. It is therefore difficult to "trick" a PN into relaying invalid data. – Basil Feb 17 '15 at 2:00
  • @Basil that's cool, although I don't think it fundamentally changes anything. It just means that both the attacker and the griefer described above need a single extra IP address, and the attacker also needs to connect to several PNs. – David A. Harding Feb 17 '15 at 2:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.