Merkle tree recalculation during transaction lookup

Question

When full-node receives a request from SPV client to check if given transaction exists in the blockchain - does it always re-calculate the merkle tree on the fly in order to return merkle path + block header to SPV client for given transaction ID?

How does it look like from performance point of view? Is there is any merkle tree caching for example? Because as I understand the node will have to do the following steps:

1. Find a block in which given transaction ID exists
2. Fetch all transactions from that block
3. Calculate merkle tree
4. Return merkle path with relevant hashes necessary to confirm merkle root

Answer 1

First of all: Bitcoin Core by default does not support BIP37 anymore, because it can be used as a computational, disk I/O, and bandwidth attack (because of points you bring up), and it has very weak privacy properties to begin with. It can still be enabled using -peerbloomfilters, but more modern approaches shouldn't depend on it.

1. Find a block in which given transaction ID exists

There is no way to issue a request for arbitrary transactions in the P2P protocol. You can only ask for recently-announce transactions (by txid, or wtxid), or for confirmed blocks (by block hash).

In the case of BIP37, it is possible for the client to send a filter of "interesting" addresses/scripts/transactions to the server, and then ask for blocks. The server will then filter the block for transactions that match the filter, and respond with those. But this does require the client to request all blocks individually - it cannot ask the server to go look for a certain transaction anywhere.

2. Fetch all transactions from that block
3. Calculate merkle tree
4. Return merkle path with relevant hashes necessary to confirm merkle root

These steps are right, for the case where a client asks for a filtered block from a server.