<p>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.</p>

<p>For example, if there are 101 psuedo-nodes (PNs) connected together, you can send PN1 a valid-looking <a href="https://bitcoin.org/en/developer-reference#inv" rel="nofollow"><code>inv</code> packet</a> announcing a single fake transaction (about 61 bytes plus TCP packet overhead).  Each PN relays that <code>inv</code> for a minimum of 6100 wasted upload bytes.  </p>

<p>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 <code>inv</code>.  Worse, the real nodes are going to request the transaction using a 61-byte <a href="https://bitcoin.org/en/developer-reference#getdata" rel="nofollow"><code>getdata</code> packet</a>, wasting 30,500 bytes of real node upload bandwidth.</p>

<p>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 <em>terabytes</em> of aggregate PN upload bandwidth and potentially 43 terabytes of real node upload bandwidth.</p>

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

<p>Compare this to the cost of running the attack against a single real node.  For each 61-byte <code>inv</code> packet the attacker uploads, the real node replies by uploading a single 61-byte <code>getdata</code>.  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 <code>inv</code> until it receives and validates the transaction it refers to, so no other node has any wasted bandwidth.</p>

<blockquote>
  <p>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)?</p>
</blockquote>

<p>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.</p>

<p>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.</p>

<p>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 <a href="https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919" rel="nofollow">proof of storage to make distributed resource
consumption
costly</a>
could be used.</p>

CC BY-SA 3.0
2015-02-15T16:16:08.893Z
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
CC BY-SA 3.0
2015-02-15T17:30:00.840Z
@WizardOfOzzie edited to answer the second part of your question.
David A. Harding
CC BY-SA 3.0
2015-02-15T18:01:58.200Z
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
CC BY-SA 3.0
2015-02-17T02:00:15.347Z
@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
CC BY-SA 3.0
2015-02-17T02:47:39.937Z
@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
CC BY-SA 3.0
2015-02-17T03:10:05.117Z
I should have also mentioned that PN does not trust inbound connections.  So it only counts invs seen from outbound peers.  Otherwise it would be easy to trick PN as you describe.
Basil
CC BY-SA 3.0
2015-02-17T03:40:40.370Z
@Basil Heh.  Good idea!  That certainly makes attacks using PNs much less trivial.  I'm guessing it's still easy to detect a PN by sending a node bad data, such as a bad transaction in a non-`inv`ed `tx` message (the way BitcoinJ sends transactions in SPV mode), and then waiting to see if the node disconnects.
David A. Harding
CC BY-SA 3.0
2015-02-15T13:59:49.590Z
2015-02-15T17:29:26.573Z
2015-02-15T17:29:26.573Z
David A. Harding
<p><a href="http://www.reddit.com/r/Bitcoin/comments/2vv8m6/pseudonode_when_is_a_full_node_a_full_node/" rel="nofollow noreferrer">Pseudo-Node</a> is discussed here on Reddit's <em><a href="http://www.reddit.com/r/Bitcoin" rel="nofollow noreferrer">/r/Bitcoin</a></em></p>
<p>Essentially it functions to relay calls from connected nodes in a random fashion.</p>
<blockquote>
<p>This was an experiment into how easily can full nodes be &quot;faked&quot;.  In conclusion: very easily.</p>
<p>A proof-of-concept implementation (&amp; documentation) is available here:</p>
<p><a href="https://github.com/basil00/PseudoNode" rel="nofollow noreferrer">https://github.com/basil00/PseudoNode</a></p>
<p>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.</p>
<p>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 &quot;sync&quot; with the network within seconds.</p>
<p>PseudoNode demonstrates some of the problems with incentivized full nodes (including the &quot;Bitnodes Incentive Program&quot;).  It is difficult to prove that a full node is really a full node.</p>
<p>The implementation mostly has novelty/proof-of-concept value.  It is not intended to be &quot;production&quot; software.</p>
</blockquote>
<p>And the <a href="https://github.com/simcity4242/PseudoNode/blob/master/README.md" rel="nofollow noreferrer">FAQ</a>:</p>
<blockquote>
<p><strong>Does PseudoNode harm the network?</strong></p>
<p>Short answer: No.</p>
<p>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.</p>
<p><strong>Can PseudoNode cause the network to fork?</strong></p>
<p>No, PseudoNode just follows what other nodes are doing.</p>
<p><strong>Can PseudoNode steal coins?</strong></p>
<p>No.</p>
<p><strong>Can PseudoNodes be banned from the network?</strong></p>
<p>Not easily. Requests that PseudoNode cannot handle directly can always be forwarded to other (cooperative) full nodes.</p>
</blockquote>
<p>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 &quot;novelty&quot; (self-described by the developer), several cons seem immediately evident:</p>
<ol>
<li>Latency will effectively increase blockchain download times such that <code>new latency = original latency * performance decrease %</code></li>
<li>Nefarious pseudonode could throttle latency to just above the threshold of the nodes enforcing blacklisting (ie <code>throttled latency</code> ~&gt; <code>cutoff latency</code>)</li>
<li>An increased percentage of nefarious nodes could possibly execute a Sybil Attack (?)</li>
</ol>
<p>2 related questions:</p>
<ol>
<li>What other attack vectors (in high-level terms) and their
repercussions could be expected from Pseudo-Nodes?</li>
<li>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)?</li>
</ol>

CC BY-SA 3.0
2015-02-15T01:02:41.743Z
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
CC BY-SA 3.0
2015-02-15T01:05:50.103Z
@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
CC BY-SA 3.0
2015-02-17T03:11:50.687Z
@WizardOfOzzie All of the "attacks" 1..3 are possible with normal full nodes.
Basil
<security><protocol><network><attack><nodes>
Pseudo-Node and putative attack vectors on the network
Wizard Of Ozzie
# Pseudo-Node and putative attack vectors on the network

(Asked by: username_0 on 2015-02-15)

[Pseudo-Node](http://www.reddit.com/r/Bitcoin/comments/2vv8m6/pseudonode_when_is_a_full_node_a_full_node/) is discussed here on Reddit's *[/r/Bitcoin](http://www.reddit.com/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](https://github.com/simcity4242/PseudoNode/blob/master/README.md):

> **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)?

**Tags:** security, protocol, network, attack, nodes

> **Comments:**
> **username_1**: 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?  
> **username_0**: @username_1 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?  
> **username_2**: @username_0 All of the "attacks" 1..3 are possible with normal full nodes.  

---

## 1 answers

### Answer by username_3 on 2015-02-15. Score: 2 | Accepted answer

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](https://bitcoin.org/en/developer-reference#inv) 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](https://bitcoin.org/en/developer-reference#getdata), 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](https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919)
could be used.

> **Comments:**
> **username_0**: 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.  
> **username_3**: @username_0 edited to answer the second part of your question.  
> **username_0**: 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  
> **username_2**: @username_3 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.  
> **username_3**: @username_2 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.  
> **username_2**: I should have also mentioned that PN does not trust inbound connections.  So it only counts invs seen from outbound peers.  Otherwise it would be easy to trick PN as you describe.  
> **username_3**: @username_2 Heh.  Good idea!  That certainly makes attacks using PNs much less trivial.  I'm guessing it's still easy to detect a PN by sending a node bad data, such as a bad transaction in a non-`inv`ed `tx` message (the way BitcoinJ sends transactions in SPV mode), and then waiting to see if the node disconnects.  

---

