How do SPV clients acquire transactions from other nodes and verify that they are part of the blockchain?

Question

I explored SPV clients as a subject from a lot of different resources, but there are a few of things that are keeping me confused:

---

1. I found out that SPV clients have no mempool even though SPV clients are participating in transaction verification. So, what happens when the node verifies a transaction? Is a SPV client checking only its own outgoing transactions?
2. Does a transaction that a SPV client is trying to verify have a block hash as a reference where the transaction came from? Is that how a SPV client knows in which block to search for the target transaction when the SPV asks a full node for part of Merkle tree?
3. A SPV client asks a full node for hashes inside the Merkle tree, so it can reconstruct the part of the tree it is interested in and checks that way if a transaction is really in the block that the transaction is referring to. Is this correct? And if it is, is there anything more these two clients share?
4. If I'm on the right path, how do bloom filters help in increasing of level of privacy since SPV clients still needs to ask a full node for a transaction by its hash?

---

Thank you.

Answer 1

1. I found out that SPV has no mempool, but although SPV client is participating in transaction verification. So, what happens when node verifies transaction? Is SPV client checking only owner's outgoing transactions?

That depends on what you mean by "verification". SPV clients cannot and do not verify the validity of transactions themselves; they can only verify that they were included in a block, relying on the assumption that miners would not waste their energy on creating a block with invalid transactions in it.

2. Transaction that SPV client is trying to verify has block hash as a reference where did a transaction came from? That's how SPV client knows in which block to search for target transaction when SPV asks full node for part of Markle tree. Is this correct?

Transactions do not (and cannot) contain a hash of the block they're contained it; that would be a cyclic dependency. I don't understand the rest of this question.

3. SPV client asks full node client for hashes inside Merkle Tree, so he can reconstruct the part of the tree of his interest and that way check if transaction is really in the block that transaction is referring to.

When using BIP37, the client sends a Bloom filter of which scripts/addresses/utxos they're interested in, and then requests blocks. The server responds with filtered blocks, containing only the matching transactions, plus efficient Merkle proofs that those transactions are actually in a block with the claimed hash.

4. If I'm on a right path, how does bloom filters help in increasing of level of privacy since SPV client still needs to ask full node client for a transaction by its hash?

BIP37 bloom filters are primarily a way to improve efficiency - it means that with little bandwidth overhead, the server knows what to not send to the client. It was intended to optionally offer some moderate level of privacy, because a client can choose to send an overly broad filter, resulting in false positives. It has since been discovered that this basically offers no privacy at all, due to correlation the server can still observe between requested things.