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.

1 Answer 1


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.