<p>Under the assumption that the total node count is large enough that we don't have to care about the reduction of the ratio by only connecting to nodes we haven't connected to, yet: </p>

<p>The chance to connect to five bad nodes in a row is 0.3<sup>5</sup> = 0.00243 = 0.243%. AFAIK, many SPV nodes only connect to 4 nodes, though. The probability then is 0.81%.</p>

CC BY-SA 3.0
2018-04-24T03:36:31.280Z
Is spv scalable? I thought it connects to one node, the quickest one?
Kyle Graham
CC BY-SA 3.0
2018-04-24T03:46:07.163Z
No, SPV nodes can be lied to by omission. Therefore, SPV nodes must connect to multiple nodes to have good odds of receiving the information they're requesting. According to this (old and potentially unreliable) wiki entry, four connections are common for SPV nodes: https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes#Very_roughly_estimating_the_total_node_count
Murch
CC BY-SA 3.0
2018-04-24T03:57:20.510Z
Makes sense, thanks for the link. Do people care about their mobile wallet being SPV? Connecting to multiple APIs seems faster and easier. What are your thoughts on SPV, Murch? I can imagine that with 10 different cryptocurrencies, SPV becomes more troublesome to scale In terms of storage and bandwidth
Kyle Graham
CC BY-SA 3.0
2018-04-24T04:07:20.770Z
Generally, the tradeoffs of thin clients are reasonably good that they can be used for smaller amounts. I'd recommend to wait for a few confirmations before relying on payments. Thin clients usually only check and store the block headers which is actually not all that much storage and bandwidth. In fact, their biggest cost is that of introducing computational load on the full nodes that serve them which need to filter their blockchain data with the requested bloomfilters. This is improved, though, by advances like roasbeef's Neutrino client which uses Compact Client Side Filtering.
Murch
CC BY-SA 3.0
2018-04-24T04:12:01.883Z
That’s a great response.
Kyle Graham
CC BY-SA 3.0
2018-04-24T04:16:06.357Z
With HD Wallets, having 1000 addresses would be slow to requery in case someone sends to a previous address. I think I have a bad perception of SPV from using BreadWallet, which is for the most part slow
Kyle Graham
CC BY-SA 3.0
2018-04-24T04:17:17.587Z
If you're interested in scalability of thin clients, I can recommend Jameson's comprehensive essay: https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim/
If you have a follow-up question, it might be better to start another topic. ;)
Murch
CC BY-SA 3.0
2018-04-24T04:44:13.587Z
Thanks for the link. Haha I do have more questions based off of that article, I will ponder them for now. Thanks again Murch!
Kyle Graham
CC BY-SA 3.0
2018-04-24T02:59:56.503Z
2018-04-24T02:59:56.503Z
Murch
<p>If we assume that 30% of the network is malicious and colluding together to trick an SPV client, by telling him wrong information.</p>

<p>How many random connections would the SPV client, need to connect to before the probability that he has only connected to malicious nodes is negligible?</p>

<p>In other words:</p>

<p>If we assume that the SPV does not know that 30% of the network is bad. What is the probability that he randomly connects to 5 bad nodes in a row?</p>

<bitcoin-core><bitcoind><client><spv>
If 30% of the network are malicious, how many nodes would an SPV need to connect to, to be sure?
Kyle Graham
# If 30% of the network are malicious, how many nodes would an SPV need to connect to, to be sure?

(Asked by: username_0 on 2018-04-23)

If we assume that 30% of the network is malicious and colluding together to trick an SPV client, by telling him wrong information.

How many random connections would the SPV client, need to connect to before the probability that he has only connected to malicious nodes is negligible?

In other words:

If we assume that the SPV does not know that 30% of the network is bad. What is the probability that he randomly connects to 5 bad nodes in a row?

**Tags:** bitcoin-core, bitcoind, client, spv


---

## 1 answers

### Answer by username_1 on 2018-04-24. Score: 2 | Accepted answer

Under the assumption that the total node count is large enough that we don't have to care about the reduction of the ratio by only connecting to nodes we haven't connected to, yet:

The chance to connect to five bad nodes in a row is 0.35 = 0.00243 = 0.243%. AFAIK, many SPV nodes only connect to 4 nodes, though. The probability then is 0.81%.

> **Comments:**
> **username_0**: Is spv scalable? I thought it connects to one node, the quickest one?  
> **username_1**: No, SPV nodes can be lied to by omission. Therefore, SPV nodes must connect to multiple nodes to have good odds of receiving the information they're requesting. According to this (old and potentially unreliable) wiki entry, four connections are common for SPV nodes: https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes#Very_roughly_estimating_the_total_node_count  
> **username_0**: Makes sense, thanks for the link. Do people care about their mobile wallet being SPV? Connecting to multiple APIs seems faster and easier. What are your thoughts on SPV, username_1? I can imagine that with 10 different cryptocurrencies, SPV becomes more troublesome to scale In terms of storage and bandwidth  
> **username_1**: Generally, the tradeoffs of thin clients are reasonably good that they can be used for smaller amounts. I'd recommend to wait for a few confirmations before relying on payments. Thin clients usually only check and store the block headers which is actually not all that much storage and bandwidth. In fact, their biggest cost is that of introducing computational load on the full nodes that serve them which need to filter their blockchain data with the requested bloomfilters. This is improved, though, by advances like roasbeef's Neutrino client which uses Compact Client Side Filtering.  
> **username_0**: That’s a great response.  
> **username_0**: With HD Wallets, having 1000 addresses would be slow to requery in case someone sends to a previous address. I think I have a bad perception of SPV from using BreadWallet, which is for the most part slow  
> **username_1**: If you're interested in scalability of thin clients, I can recommend Jameson's comprehensive essay: https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim/ If you have a follow-up question, it might be better to start another topic. ;)  
> **username_0**: Thanks for the link. Haha I do have more questions based off of that article, I will ponder them for now. Thanks again username_1!  

---

