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:
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?
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:
- Latency will effectively increase blockchain download times such that
new latency = original latency * performance decrease %
- Nefarious pseudonode could throttle latency to just above the threshold of the nodes enforcing blacklisting (ie
- An increased percentage of nefarious nodes could possibly execute a Sybil Attack (?)
2 related questions:
- What other attack vectors (in high-level terms) and their repercussions could be expected from Pseudo-Nodes?
- 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)?