<blockquote>
  <p>They may dislike compute to find transaction if they have to sequence search because they are busy to find hash value of block to earn block reward</p>
</blockquote>

<p>You are confusing mining with node operation. </p>

<p>It is a full node on the network that will return info about the relevant merkle path to the SPV wallet. </p>

<p>Mining is done separately, by specialized hardware that is built to <em>only</em> be extremely efficient at hashing to find a new block. The mining hardware will be connected to a full node, so that it can obtain the relevant info to build new block templates. But the two computations are done on separate hardware, in parallel. </p>

<p>So even if a miner’s node was the one to serve the merkle path info, it would not take away from their mining time. </p>

CC BY-SA 4.0
2019-09-01T13:56:08.627Z
Thansk for reply. yes, I think your answer is right, but you didn't include answer of my core question, "how full-node provide efficiently merkle path?", can you show what you think about my question? I would like to hear about this!
Hyunsoo
CC BY-SA 4.0
2019-08-31T22:50:32.930Z
2019-08-31T22:50:32.930Z
chytrik
<p>Firstly I don't know about the implementation details, so maybe I have some misunderstanding. However I still think I can help. Correct me if I'm wrong :-D.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">BIP37</a> protocol allows the full node to find out relevant transactions from the blockchain ledger with bloom filters, so that the lightweight client would not have to download the full blocks. However it's still very inefficient. It's much less efficient than a fully indexed server like ElectrumX, Electrs etc. The full node still needs to scan the blockchain, which requires reading the hard drive intensively.</p>
<p>Note that Electrum protocol (essentially) requires the lightweight client to send its addresses directly, so that its privacy is not good.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki" rel="nofollow noreferrer">BIP157</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki" rel="nofollow noreferrer">158</a> (aka Neutrino) protocol let the full node build a block filter index in advance, so that a lightweight client only needs to download the block filter index only firstly. With such block fitler index, the lightweight client can scan through the filters to find out which blocks may be relevant, and then it can download those possibly relevant blocks to scan out the relevant transactions from them.</p>
<p>Neutrino protocol is still not as efficient as a fully indexed server, like an Electrum server (or an online block explorer), however it's efficient enough to allow an ordinary laptop to scan though the whole blockchain in only 1-2 minutes, which is almostly two orders of magitudes more efficient than directly scanning the blockchain itself. The block filter index also takes much lower disk space than a fully indexed server. The bandwith consumption is obviously higher because the block filter index currently takes ~5GB, however once it's completely downloaded, it can be then reused freely.</p>
<p>However, Andreas Schildbach, maintainer of <a href="https://github.com/bitcoinj/bitcoinj" rel="nofollow noreferrer">bitcoinj</a> and the <a href="https://github.com/bitcoin-wallet/bitcoin-wallet" rel="nofollow noreferrer">bitcoin-wallet</a> for Android, thinks that Neutrino still has <a href="https://github.com/bitcoin-wallet/bitcoin-wallet/issues/358#issuecomment-480823209" rel="nofollow noreferrer">some limitations/problems</a>, so that it's not really an alternative of BIP37.</p>
<hr />
<p>By the way, what a Merkle proof can do is very much limited than what a lot of people supposed.</p>
<p><strong>Merkle path proves nothing but the existence of the transaction data itself, which is essentially just a timestamp.</strong> This fact essentially makes the &quot;reclaiming disk space&quot; mentioned in Satoshi' s whitepaper <a href="https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#7-reclaiming-disk-space" rel="nofollow noreferrer">unrealistic</a>.</p>
<p>SPV light clients are facing <a href="https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#8-simplified-payment-verification" rel="nofollow noreferrer">similar problem</a>, that even Satoshi himself also mentioned that SPV &quot;can be fooled by an attacker's fabricated transactions&quot;, while unfortunately the countermeasure (aka &quot;fraud proofs&quot; nowadays) which Satoshi assumed seems impossible (or always incomplete) in reality.</p>

CC BY-SA 4.0
2020-06-27T03:23:13.913Z
2020-06-27T04:54:24.260Z
2020-06-27T04:54:24.260Z
Chris Chen
<p>In the Bitcoin, SPV node can query that its transaction is included specific block to full node that provides merkle path which has super fast calculation.</p>

<p>In terms of full nodes, they have full-ledger and merkle tree that is consist of transaction tree. so they can find some transaction queried by SPV node(light node) but my question is that how they can <strong>efficiently</strong> find it?</p>

<p>They may dislike compute to find transaction if they have to sequence search because they are busy to find hash value of block to earn block reward.</p>

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

CC BY-SA 4.0
2019-10-01T00:45:45.910Z
related: https://btcinformation.org/en/developer-reference#merkleblock
Murch
<bitcoin-core><transactions><merkleblock>
What is a mechanism of providing Merkle Path?
Hyunsoo
# What is a mechanism of providing Merkle Path?

(Asked by: username_0 on 2019-08-31)

In the Bitcoin, SPV node can query that its transaction is included specific block to full node that provides merkle path which has super fast calculation.

In terms of full nodes, they have full-ledger and merkle tree that is consist of transaction tree. so they can find some transaction queried by SPV node(light node) but my question is that how they can **efficiently** find it?

They may dislike compute to find transaction if they have to sequence search because they are busy to find hash value of block to earn block reward.

Sorry for my English.

**Tags:** bitcoin-core, transactions, merkleblock

> **Comments:**
> **username_1**: related: https://btcinformation.org/en/developer-reference#merkleblock  

---

## 2 answers

### Answer by username_2 on 2019-08-31. Score: 1

> They may dislike compute to find transaction if they have to sequence search because they are busy to find hash value of block to earn block reward

You are confusing mining with node operation.

It is a full node on the network that will return info about the relevant merkle path to the SPV wallet.

Mining is done separately, by specialized hardware that is built to *only* be extremely efficient at hashing to find a new block. The mining hardware will be connected to a full node, so that it can obtain the relevant info to build new block templates. But the two computations are done on separate hardware, in parallel.

So even if a miner’s node was the one to serve the merkle path info, it would not take away from their mining time.

> **Comments:**
> **username_0**: Thansk for reply. yes, I think your answer is right, but you didn't include answer of my core question, "how full-node provide efficiently merkle path?", can you show what you think about my question? I would like to hear about this!  

---

### Answer by username_3 on 2020-06-27. Score: 0

Firstly I don't know about the implementation details, so maybe I have some misunderstanding. However I still think I can help. Correct me if I'm wrong :-D.

[BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) protocol allows the full node to find out relevant transactions from the blockchain ledger with bloom filters, so that the lightweight client would not have to download the full blocks. However it's still very inefficient. It's much less efficient than a fully indexed server like ElectrumX, Electrs etc. The full node still needs to scan the blockchain, which requires reading the hard drive intensively.

Note that Electrum protocol (essentially) requires the lightweight client to send its addresses directly, so that its privacy is not good.

[BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki)/[158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki) (aka Neutrino) protocol let the full node build a block filter index in advance, so that a lightweight client only needs to download the block filter index only firstly. With such block fitler index, the lightweight client can scan through the filters to find out which blocks may be relevant, and then it can download those possibly relevant blocks to scan out the relevant transactions from them.

Neutrino protocol is still not as efficient as a fully indexed server, like an Electrum server (or an online block explorer), however it's efficient enough to allow an ordinary laptop to scan though the whole blockchain in only 1-2 minutes, which is almostly two orders of magitudes more efficient than directly scanning the blockchain itself. The block filter index also takes much lower disk space than a fully indexed server. The bandwith consumption is obviously higher because the block filter index currently takes ~5GB, however once it's completely downloaded, it can be then reused freely.

However, Andreas Schildbach, maintainer of [bitcoinj](https://github.com/bitcoinj/bitcoinj) and the [bitcoin-wallet](https://github.com/bitcoin-wallet/bitcoin-wallet) for Android, thinks that Neutrino still has [some limitations/problems](https://github.com/bitcoin-wallet/bitcoin-wallet/issues/358#issuecomment-480823209), so that it's not really an alternative of BIP37.

---

By the way, what a Merkle proof can do is very much limited than what a lot of people supposed.

**Merkle path proves nothing but the existence of the transaction data itself, which is essentially just a timestamp.** This fact essentially makes the "reclaiming disk space" mentioned in Satoshi' s whitepaper [unrealistic](https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#7-reclaiming-disk-space).

SPV light clients are facing [similar problem](https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#8-simplified-payment-verification), that even Satoshi himself also mentioned that SPV "can be fooled by an attacker's fabricated transactions", while unfortunately the countermeasure (aka "fraud proofs" nowadays) which Satoshi assumed seems impossible (or always incomplete) in reality.


---

