<blockquote>
  <p>Is there a way currently where an SPV client can send a TxID to a full node which is present in the UTXO set of the full node and have the full node not scan its entire blockchain to fetch the transaction data? Or under all the circumstances, the full node would always scan the entire blockchain to fetch the data?</p>
</blockquote>

<p>A full node never scans the entire blockchain for a particular transaction to send to a SPV client. No client (SPV or not) can just request transactions that are in the blockchain; a node will not respond to such a request because it is computationally expensive (requires scanning the blockchain).</p>

<p>A SPV client can set a bloom filter which will filter for specific outputs and txids, and then request blocks from a full node. The node will send a filtered block to the SPV client then.</p>

<p>So no, a SPV client can't send a txid to a full node and get the transaction if it is already confirmed.</p>

<p>For SPV clients that use a client server model like electrum, the server is a full node which has indexed every single transaction in the blockchain (it maintains a database which maps txids to locations on disk). Those servers will respond to requests for specific txids, but they are not your typical full node and speak a different protocol.</p>

<blockquote>
  <p>Also, do the full nodes along with the transaction data also return the merkle proof to prove the validity of the data returned? I mean, how can an SPV node be convinced that the correct data has been returned?</p>
</blockquote>

<p>Merkle proofs are provided by the nodes to prove that the transaction is in the block.</p>

CC BY-SA 4.0
2018-11-19T18:49:10.807Z
But don't the full nodes (as mentioned in [link](https://bitcoin.stackexchange.com/questions/28168/what-are-the-keys-used-in-the-blockchain-leveldb-ie-what-are-the-keyvalue-pair) post) with -txindex flag set also maintain an index that maps TxID to some information that lets them  retrieve transaction data efficiently. Wouldn't the full nodes, in this case, retrieve transaction data for SPV client queries on TxID?
archita
CC BY-SA 4.0
2018-11-19T21:01:09.417Z
No. While `-txindex` allows nodes to maintain a transaction index, this data is only exposed locally to the RPC interface. It is not used for node operations. Nodes with txindex are functionally the same as those without and are not distinguishable from those without txindex without access to the RPC interface.
Ava Chow
CC BY-SA 4.0
2018-11-19T18:25:07.220Z
2018-11-19T18:25:07.220Z
Ava Chow
<p>Is there a way currently where an SPV client can send a TxID to a full node which is present in the UTXO set of the full node and have the full node not scan its entire blockchain to fetch the transaction data? Or under all the circumstances, the full node would always scan the entire blockchain to fetch the data?</p>

<p>Also, do the full nodes along with the transaction data also return the merkle proof to prove the validity of the data returned? I mean, how can an SPV node be convinced that the correct data has been returned?</p>

<transactions><spv><transaction-id>
SPV clients querying the full node
archita
# SPV clients querying the full node

(Asked by: username_0 on 2018-11-19)

Is there a way currently where an SPV client can send a TxID to a full node which is present in the UTXO set of the full node and have the full node not scan its entire blockchain to fetch the transaction data? Or under all the circumstances, the full node would always scan the entire blockchain to fetch the data?

Also, do the full nodes along with the transaction data also return the merkle proof to prove the validity of the data returned? I mean, how can an SPV node be convinced that the correct data has been returned?

**Tags:** transactions, spv, transaction-id


---

## 1 answers

### Answer by username_1 on 2018-11-19. Score: 1

> Is there a way currently where an SPV client can send a TxID to a full node which is present in the UTXO set of the full node and have the full node not scan its entire blockchain to fetch the transaction data? Or under all the circumstances, the full node would always scan the entire blockchain to fetch the data?

A full node never scans the entire blockchain for a particular transaction to send to a SPV client. No client (SPV or not) can just request transactions that are in the blockchain; a node will not respond to such a request because it is computationally expensive (requires scanning the blockchain).

A SPV client can set a bloom filter which will filter for specific outputs and txids, and then request blocks from a full node. The node will send a filtered block to the SPV client then.

So no, a SPV client can't send a txid to a full node and get the transaction if it is already confirmed.

For SPV clients that use a client server model like electrum, the server is a full node which has indexed every single transaction in the blockchain (it maintains a database which maps txids to locations on disk). Those servers will respond to requests for specific txids, but they are not your typical full node and speak a different protocol.

> Also, do the full nodes along with the transaction data also return the merkle proof to prove the validity of the data returned? I mean, how can an SPV node be convinced that the correct data has been returned?

Merkle proofs are provided by the nodes to prove that the transaction is in the block.

> **Comments:**
> **username_0**: But don't the full nodes (as mentioned in [link](https://bitcoin.stackexchange.com/questions/28168/what-are-the-keys-used-in-the-blockchain-leveldb-ie-what-are-the-keyvalue-pair) post) with -txindex flag set also maintain an index that maps TxID to some information that lets them  retrieve transaction data efficiently. Wouldn't the full nodes, in this case, retrieve transaction data for SPV client queries on TxID?  
> **username_1**: No. While `-txindex` allows nodes to maintain a transaction index, this data is only exposed locally to the RPC interface. It is not used for node operations. Nodes with txindex are functionally the same as those without and are not distinguishable from those without txindex without access to the RPC interface.  

---

