<p>A SPV node have to work somethings to see whether his transaction is exist or not.</p>

<ol>
<li>Construct his filter with hash of transactions {his transactions, other1, other2, ..., otherN}</li>
<li><code>filterload</code> is filled to process his filter by full-node (by BIP-0037)</li>
<li>Send to full-nodes</li>
</ol>

<p>Okay, these are responsible for SPV node and let me take a view of full-node received the filter.</p>

<ol>
<li>Lookup chain to find <strong>transaction(K)</strong> with <code>filterload</code></li>
</ol>

<p>What...? hold on.. how can the full-node know that <strong>transaction(K)</strong> is what? <code>filterload</code> has no any information of <strong>transactions(K)</strong>. <br>
<code>filterload</code> = { filter, nHashFuncs, nTweak, nFalgs } <br>
Nobody doesn't explain about this in the web, including BIP-0037. Just explains only what is a bloom filter.<br>
I think that full-node must know what transactions(K) are to find on his ledger, otherwise full-node have to see entire chain and this doesn't make sense.</p>

<p>So.. I'd like to know the proper procedure on full-node received the filter by SPV node.</p>

<p>Sorry for my English.</p>

CC BY-SA 4.0
2019-09-26T20:11:44.083Z
bip37 is disabled in new releases so you shouldn’t build anything based on it.
Claris
CC BY-SA 4.0
2019-09-27T06:01:04.830Z
I read some articles about your reply. Isn't disabling BIP37 optional, not required?
Hyunsoo
CC BY-SA 4.0
2019-09-27T20:01:11.303Z
It’s default off and will likely be removed entirely in the future.
Claris
CC BY-SA 4.0
2019-09-27T21:23:12.663Z
So, what is an alternative instead Bloom Filter?
Hyunsoo
<full-node><spv><query>
Bloom Filter Response Processing In terms of Full-node
Hyunsoo
# Bloom Filter Response Processing In terms of Full-node

(Asked by: username_0 on 2019-09-26)

A SPV node have to work somethings to see whether his transaction is exist or not.

1. Construct his filter with hash of transactions {his transactions, other1, other2, ..., otherN}
2. `filterload` is filled to process his filter by full-node (by BIP-0037)
3. Send to full-nodes

Okay, these are responsible for SPV node and let me take a view of full-node received the filter.

1. Lookup chain to find **transaction(K)** with `filterload`

What...? hold on.. how can the full-node know that **transaction(K)** is what? `filterload` has no any information of **transactions(K)**.   
`filterload` = { filter, nHashFuncs, nTweak, nFalgs }   
Nobody doesn't explain about this in the web, including BIP-0037. Just explains only what is a bloom filter.  
I think that full-node must know what transactions(K) are to find on his ledger, otherwise full-node have to see entire chain and this doesn't make sense.

So.. I'd like to know the proper procedure on full-node received the filter by SPV node.

Sorry for my English.

**Tags:** full-node, spv, query

> **Comments:**
> **username_1**: bip37 is disabled in new releases so you shouldn’t build anything based on it.  
> **username_0**: I read some articles about your reply. Isn't disabling BIP37 optional, not required?  
> **username_1**: It’s default off and will likely be removed entirely in the future.  
> **username_0**: So, what is an alternative instead Bloom Filter?  

---

## 0 answers

