<p><strong>That is based on the minimum indexing required to run a full-node.</strong></p>

<p>A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively. </p>

<p>Confirmed transaction are supplied as part of getdata request with blockhashes. Blocks are indexed by all full-nodes. (Since new block-headers must reference previous headers, even if they are branch-extending, vs strong-chain extending)</p>

<p><strong>Correction(see comment below):</strong> </p>

CC BY-SA 4.0
2018-11-30T09:08:19.203Z
This is not correct. The approach suggested by OP (using BIP37) would work, but it is highly inefficient (it requires the full node scanning through the whole chain, but does not need an index). That's why of the reasons why BIP37 is being discouraged.
Pieter Wuille
CC BY-SA 4.0
2018-11-30T09:16:32.130Z
Wow, an entire chain scan? Thanks for the correction - I would never have thought that this is done without index.
James C.
CC BY-SA 4.0
2018-11-30T17:06:43.563Z
It's no different from a full blockchain download, but while giving a filter first. The BIP37 bloom filter approach can't be easily sped up using an index anyway (as an index would inherently not have false positives, and thus leak a lot of privacy). See BIP157 for a more modern approach (which uses some precomputed data, but still not an index).
Pieter Wuille
CC BY-SA 4.0
2018-11-30T07:40:43.357Z
2018-11-30T09:17:37.700Z
2018-11-30T09:17:37.700Z
James C.
<p><a href="https://en.bitcoin.it/wiki/Protocol_documentation#getdata" rel="nofollow noreferrer">This</a> link mentions that </p>

<p>"[<em>getdata</em>] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed..."</p>

<p>But can't an SPV node do the following to have the arbitrary access to a transaction T (I am assuming that the SPV node knows the block hash H of the block B containing T):</p>

<ol>
<li>set a bloom filter using <em>filterload</em> for T at some full node</li>
<li>send <em>getdata</em> request with type MSG_FILTERED_BLOCK and block hash H</li>
<li>then in response, the full node will generate two messages for the SPV node: first, a merkleblock of B; and second, the transaction T (as mentioned <a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">here</a> and <a href="https://bitcoin.stackexchange.com/questions/11054/how-do-spv-simple-payment-verification-wallets-learn-about-incoming-transactio">here</a>)</li>
</ol>

<p>Doesn't this mechanism actually gives arbitrary access to transactions?</p>

CC BY-SA 4.0
2018-11-30T07:43:13.503Z
That only works for a node which has transaction-index activated. If it doesn’t, it would not offer this service during the p2p handshake (version message indicates available services), and it would not be possible with this peer.
James C.
<transactions><wallet><spv><bip37-bloom-filter>
Arbitrary access to already confirmed transactions
archita
# Arbitrary access to already confirmed transactions

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

[This](https://en.bitcoin.it/wiki/Protocol_documentation#getdata) link mentions that

"[*getdata*] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed..."

But can't an SPV node do the following to have the arbitrary access to a transaction T (I am assuming that the SPV node knows the block hash H of the block B containing T):

1. set a bloom filter using *filterload* for T at some full node
2. send *getdata* request with type MSG\_FILTERED\_BLOCK and block hash H
3. then in response, the full node will generate two messages for the SPV node: first, a merkleblock of B; and second, the transaction T (as mentioned [here](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) and [here](https://bitcoin.stackexchange.com/questions/11054/how-do-spv-simple-payment-verification-wallets-learn-about-incoming-transactio))

Doesn't this mechanism actually gives arbitrary access to transactions?

**Tags:** transactions, wallet, spv, bip37-bloom-filter

> **Comments:**
> **username_1**: That only works for a node which has transaction-index activated. If it doesn’t, it would not offer this service during the p2p handshake (version message indicates available services), and it would not be possible with this peer.  

---

## 1 answers

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

**That is based on the minimum indexing required to run a full-node.**

A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively.

Confirmed transaction are supplied as part of getdata request with blockhashes. Blocks are indexed by all full-nodes. (Since new block-headers must reference previous headers, even if they are branch-extending, vs strong-chain extending)

**Correction(see comment below):**

> **Comments:**
> **username_2**: This is not correct. The approach suggested by OP (using BIP37) would work, but it is highly inefficient (it requires the full node scanning through the whole chain, but does not need an index). That's why of the reasons why BIP37 is being discouraged.  
> **username_1**: Wow, an entire chain scan? Thanks for the correction - I would never have thought that this is done without index.  
> **username_2**: It's no different from a full blockchain download, but while giving a filter first. The BIP37 bloom filter approach can't be easily sped up using an index anyway (as an index would inherently not have false positives, and thus leak a lot of privacy). See BIP157 for a more modern approach (which uses some precomputed data, but still not an index).  

---

