<p>It can't. However, it is sufficient to request the information from a single honest peer, as the proof does work in the other direction.</p>

<p>This is one of the major drawbacks of using <a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">BIP37</a> for learning about transactions (other downsides include <a href="https://www.youtube.com/watch?v=HScK4pkDNds" rel="nofollow noreferrer">terrible privacy</a> and high load on the servers you're fetching from).</p>

<p>Several proposals exist to improve this, including <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html" rel="nofollow noreferrer">Committed Bloom Filter</a> and committed adress-indexed UTXO sets. None of them have been implemented, however.</p>

CC BY-SA 3.0
2017-01-09T19:22:19.090Z
2017-01-09T19:22:19.090Z
Pieter Wuille
<p>With merkle trees, a light client can be sure some transactions he receives are correct with a minimal amount of the blockchain data. How can such a client, though, be sure he received <em>all</em> the relevant transactions from/to his address, in order to know his full balance? What if his peer censured some transactions for some reason?</p>

<transactions><wallet><address><security>
How can a light client be certain he got all relevant transactions?
MaiaVictor
# How can a light client be certain he got all relevant transactions?

(Asked by: username_0 on 2017-01-09)

With merkle trees, a light client can be sure some transactions he receives are correct with a minimal amount of the blockchain data. How can such a client, though, be sure he received *all* the relevant transactions from/to his address, in order to know his full balance? What if his peer censured some transactions for some reason?

**Tags:** transactions, wallet, address, security


---

## 1 answers

### Answer by username_1 on 2017-01-09. Score: 1 | Accepted answer

It can't. However, it is sufficient to request the information from a single honest peer, as the proof does work in the other direction.

This is one of the major drawbacks of using [BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) for learning about transactions (other downsides include [terrible privacy](https://www.youtube.com/watch?v=HScK4pkDNds) and high load on the servers you're fetching from).

Several proposals exist to improve this, including [Committed Bloom Filter](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html) and committed adress-indexed UTXO sets. None of them have been implemented, however.


---

