<p>Peers who don't use the whole blockchain are relying on at least one of their peers to send them transaction data when a transaction satisfies the bloom filter that the SPV (simplified payment verification) node has set. As such, SPV nodes have to be careful about which peers they connect to, and that they have a variety of peers. I believe some implementations of SPV nodes only connect to a set of defined, or are at least configurable to only connect to a strict set of peers. </p>

<p>Read how the bitcoinj (SPV node implementation) creator describes its security <a href="https://bitcoinj.github.io/security-model" rel="nofollow">here</a>:</p>

<blockquote>
  <p>Because bitcoinj apps do not accept incoming connections, the peers you talk to are always randomly selected at startup (based on DNS seeds today). So it can be difficult for an attacker to control your connectivity like that. For this reason, the number of peers that have announced a transaction is exposed in the TransactionConfidence object and you can listen on that to learn when new peers have announced a transaction. Once most of your peers have announced, you can be fairly sure that the transaction is propagating its way across the network and is very likely to be valid.</p>
</blockquote>

CC BY-SA 3.0
2015-03-29T05:05:26.070Z
interesting. if i understand it correctly, dns-seeds just pick randomly from the available client ip addresses? if so then i think a malicious network admin (eg at the isp level) could limit your connection down to only unreliable peers who then omit txs. its far fetched, i know, but still...
mulllhausen
CC BY-SA 3.0
2015-03-29T03:48:11.090Z
2015-04-01T12:13:20.213Z
2015-04-01T12:13:20.213Z
morsecoder
<p>is there a way for a non-full node (ie a node which does not contain the full blockchain) to know when it has received all transactions associated with an address? i understand that it is possible for a non-full node to tell if it has been fed an invalid transaction - the node can check that the transaction hash exists in the pruned merkle tree for the specified block, then compute the merkle root for that tree and check it exists in the block header. but i don't know of any checks to ensure that all transactions have been downloaded.</p>

<p>if transactions are not relayed by a malicious remote node then the target node will think it has less funds available than it really does.</p>

<p>i had thought that bloom filters might fix this problem, but i read in bip37:</p>

<blockquote>
  <p>Thus, a merkleblock message is a block header, plus a part of a merkle
  tree which can be used to extract identifying information for
  transactions that matched the filter and prove that the matching
  transaction data really did appear in the solved block. Clients can
  use this data to be sure that the remote node is not feeding them fake
  transactions that never appeared in a real block, although lying
  through omission is still possible.</p>
</blockquote>

<p>so it seems bip37 does not attempt to solve this issue.</p>

<thin-clients>
thin-client remote node lying through omission
mulllhausen
# thin-client remote node lying through omission

(Asked by: username_0 on 2015-03-29)

is there a way for a non-full node (ie a node which does not contain the full blockchain) to know when it has received all transactions associated with an address? i understand that it is possible for a non-full node to tell if it has been fed an invalid transaction - the node can check that the transaction hash exists in the pruned merkle tree for the specified block, then compute the merkle root for that tree and check it exists in the block header. but i don't know of any checks to ensure that all transactions have been downloaded.

if transactions are not relayed by a malicious remote node then the target node will think it has less funds available than it really does.

i had thought that bloom filters might fix this problem, but i read in bip37:

> Thus, a merkleblock message is a block header, plus a part of a merkle
> tree which can be used to extract identifying information for
> transactions that matched the filter and prove that the matching
> transaction data really did appear in the solved block. Clients can
> use this data to be sure that the remote node is not feeding them fake
> transactions that never appeared in a real block, although lying
> through omission is still possible.

so it seems bip37 does not attempt to solve this issue.

**Tags:** thin-clients


---

## 1 answers

### Answer by username_1 on 2015-03-29. Score: 2

Peers who don't use the whole blockchain are relying on at least one of their peers to send them transaction data when a transaction satisfies the bloom filter that the SPV (simplified payment verification) node has set. As such, SPV nodes have to be careful about which peers they connect to, and that they have a variety of peers. I believe some implementations of SPV nodes only connect to a set of defined, or are at least configurable to only connect to a strict set of peers.

Read how the bitcoinj (SPV node implementation) creator describes its security [here](https://bitcoinj.github.io/security-model):

> Because bitcoinj apps do not accept incoming connections, the peers you talk to are always randomly selected at startup (based on DNS seeds today). So it can be difficult for an attacker to control your connectivity like that. For this reason, the number of peers that have announced a transaction is exposed in the TransactionConfidence object and you can listen on that to learn when new peers have announced a transaction. Once most of your peers have announced, you can be fairly sure that the transaction is propagating its way across the network and is very likely to be valid.

> **Comments:**
> **username_0**: interesting. if i understand it correctly, dns-seeds just pick randomly from the available client ip addresses? if so then i think a malicious network admin (eg at the isp level) could limit your connection down to only unreliable peers who then omit txs. its far fetched, i know, but still...  

---

