<p>Your instinct is correct: a full node can lie-by-omission to a light client and deny them proof that a transaction was included in a block. This is a well-documented vulnerability of SPV wallets and the only mitigation really is to connect to more peers (you only need one &quot;honest&quot; peer).</p>
<p>This problem is also somewhat addressed by <a href="https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki" rel="noreferrer">BIP157</a> aka &quot;Neutrino&quot;. In this protocol, the light client scans entire blocks for its own transactions. It knows which blocks to check based on filters provided by full nodes. Of course, this brings us back to the first issue: what if a full node provides an invalid filter? Eventually we might see a soft fork that requires valid filters to be inserted in some part of the block, secured by proof-of-work.</p>
<p>Currently, BIP157 offers this:</p>
<blockquote>
<p>Unless securely connected to a trusted peer that is serving filter
headers, the client SHOULD connect to multiple outbound peers that
support each filter type to mitigate the risk of downloading incorrect
headers. If the client receives conflicting filter headers from
different peers for any block and filter type, it SHOULD interrogate
them to determine which is faulty. The client SHOULD use getcfheaders
and/or getcfcheckpt to first identify the first filter headers that
the peers disagree on. The client then SHOULD download the full block
from any peer and derive the correct filter and filter header. The
client SHOULD ban any peers that sent a filter header that does not
match the computed one.</p>
</blockquote>

CC BY-SA 4.0
2020-08-26T11:22:29.813Z
2020-08-26T11:22:29.813Z
pinhead
<p>How can Merkle Trees ensure that a full node doesn't lie to a thin node that a txn t is not present in a block B if infact B contains t? How can a thin node tell if the full node is lying if the full node denies the presence of a txn t in a block B and doesn't send any hash values(for the thin node to verify) and instead claims it can't generate hashes that are not there.</p>
<p>PS: Don't mind the informal style of my questioning. I'm just trying to get an intuitive understanding of Merkle Trees at first.</p>

<bitcoin-core><blockchain><merkle-tree>
How do merkle trees ensure credibility to blockchain, when full node wrongly denies a presence of a txn in a block?
NIKHIL KOMMINENI
# How do merkle trees ensure credibility to blockchain, when full node wrongly denies a presence of a txn in a block?

(Asked by: username_0 on 2020-08-26)

How can Merkle Trees ensure that a full node doesn't lie to a thin node that a txn t is not present in a block B if infact B contains t? How can a thin node tell if the full node is lying if the full node denies the presence of a txn t in a block B and doesn't send any hash values(for the thin node to verify) and instead claims it can't generate hashes that are not there.

PS: Don't mind the informal style of my questioning. I'm just trying to get an intuitive understanding of Merkle Trees at first.

**Tags:** bitcoin-core, blockchain, merkle-tree


---

## 1 answers

### Answer by username_1 on 2020-08-26. Score: 8 | Accepted answer

Your instinct is correct: a full node can lie-by-omission to a light client and deny them proof that a transaction was included in a block. This is a well-documented vulnerability of SPV wallets and the only mitigation really is to connect to more peers (you only need one "honest" peer).

This problem is also somewhat addressed by [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) aka "Neutrino". In this protocol, the light client scans entire blocks for its own transactions. It knows which blocks to check based on filters provided by full nodes. Of course, this brings us back to the first issue: what if a full node provides an invalid filter? Eventually we might see a soft fork that requires valid filters to be inserted in some part of the block, secured by proof-of-work.

Currently, BIP157 offers this:

> Unless securely connected to a trusted peer that is serving filter
> headers, the client SHOULD connect to multiple outbound peers that
> support each filter type to mitigate the risk of downloading incorrect
> headers. If the client receives conflicting filter headers from
> different peers for any block and filter type, it SHOULD interrogate
> them to determine which is faulty. The client SHOULD use getcfheaders
> and/or getcfcheckpt to first identify the first filter headers that
> the peers disagree on. The client then SHOULD download the full block
> from any peer and derive the correct filter and filter header. The
> client SHOULD ban any peers that sent a filter header that does not
> match the computed one.


---

