<blockquote>
<p>User A send a transaction to user B. Those transactions are bundled together into a merkle tree. User A and B can both use the transaction plus the merkle root, plus the merkle path to prove the merkle root in the block header is correct.</p>
</blockquote>
<p>Let me rephrase your question to ensure we are on the same page:<br />
Alice pays Bob. When Alice submits her transaction to the network, it is still unconfirmed. The transaction gets confirmed by being included in a block. The block header includes the merkle root which is a cryptographic commitment to the included transaction set (in order).</p>
<p>Neither Alice nor Bob know the merkle path at this point. Depending on the thin client they're running, their wallet will either request a full node peer to flag transactions that match a bloom filter encoding their interests (BIP 37 (deprecated)), they trust a service provider to know their addresses (Electrum, various centralized wallet services), or they download compact client-side block filters which they can use locally to see whether a block might include anything of interest (BIP 157/158).</p>
<p>Once the thin client learns about a transaction they're interested in, the thin client either requests the merkle block for the transaction specifically or the complete block from a full node peer or their service provider. The Merkle block datastructure has all the necessary hashing partners to retrace the full branch from the transaction leaf to the root as well as the block header (as does the complete block of course). That's how they know!</p>
<p>As chytrik <a href="https://bitcoin.stackexchange.com/a/93373/5406">wrote</a> in another answer, most thin clients follow along with the network by synchronizing the block header chain. Since they do not parse the complete blocks, they do not keep track of the full ledger of bitcoin balances (the unspent transaction output set), and therefore cannot validate transactions. They can however perform basic validity checks on blocks such as whether they fulfill the current difficulty requirement, and whether the block header's content actually matches the given hash.</p>

CC BY-SA 4.0
2021-03-15T22:36:27.347Z
2021-03-15T22:36:27.347Z
Murch
<blockquote>
  <p>how do A and B know the correct merkle path without needing the entire block?</p>
</blockquote>

<p>Many light-clients will sync to the longest chain of headers, under the assumption that other nodes on the network will be checking the full content of those blocks for validity. (Consider: if every node was a light-client, miners could include invalid transactions in blocks, and none of the light-clients would know it!)</p>

<p>By requesting the intermediate states of the merkle tree from a node that has the full block, a light-client can verify that a transaction the user is interested in is indeed included in a block that is part of the longest chain, in a more efficient manner than validating the entirety of the block themselves (the caveat being the assumption of validity mentioned above).</p>

<blockquote>
  <p>Do they need a centralized provider that processes the blocks to calculate these for them? Is it possible to do in a decentralized way?</p>
</blockquote>

<p>This entirely depends on the implementation. Some light-wallets might just call back to a certain server, operated by the wallet's developers, for example. Other light-clients might attempt to pull this information from random nodes on the network. Some are even built to connect to your own node. </p>

<p>Ultimately, the highest level of certainty will come from running a fully-validating node yourself (ie, a full node). As bitcoiners like to say: don't trust, verify. </p>

CC BY-SA 4.0
2020-02-19T00:38:05.130Z
2020-02-19T00:38:05.130Z
chytrik
<p>User A send a transaction to user B. Those transactions are bundled together into a merkle tree. User A and B can both use the transaction plus the merkle root, plus the merkle path to prove the merkle root in the block header is correct.</p>

<p>I understand all that.. what I don't understand is how do A and B know the correct merkle path without needing the entire block?</p>

<p>Do they need a centralized provider that processes the blocks to calculate these for them? Is it possible to do in a decentralized way?</p>

<blockchain><transaction-verification><spv><merkleblock>
How do people using thin clients know the correct merkle path of transactions they've sent without knowing the full block?
Matthew Czarnek
# How do people using thin clients know the correct merkle path of transactions they've sent without knowing the full block?

(Asked by: username_0 on 2020-02-18)

User A send a transaction to user B. Those transactions are bundled together into a merkle tree. User A and B can both use the transaction plus the merkle root, plus the merkle path to prove the merkle root in the block header is correct.

I understand all that.. what I don't understand is how do A and B know the correct merkle path without needing the entire block?

Do they need a centralized provider that processes the blocks to calculate these for them? Is it possible to do in a decentralized way?

**Tags:** blockchain, transaction-verification, spv, merkleblock


---

## 2 answers

### Answer by username_1 on 2021-03-15. Score: 1

> User A send a transaction to user B. Those transactions are bundled together into a merkle tree. User A and B can both use the transaction plus the merkle root, plus the merkle path to prove the merkle root in the block header is correct.

Let me rephrase your question to ensure we are on the same page:  
Alice pays Bob. When Alice submits her transaction to the network, it is still unconfirmed. The transaction gets confirmed by being included in a block. The block header includes the merkle root which is a cryptographic commitment to the included transaction set (in order).

Neither Alice nor Bob know the merkle path at this point. Depending on the thin client they're running, their wallet will either request a full node peer to flag transactions that match a bloom filter encoding their interests (BIP 37 (deprecated)), they trust a service provider to know their addresses (Electrum, various centralized wallet services), or they download compact client-side block filters which they can use locally to see whether a block might include anything of interest (BIP 157/158).

Once the thin client learns about a transaction they're interested in, the thin client either requests the merkle block for the transaction specifically or the complete block from a full node peer or their service provider. The Merkle block datastructure has all the necessary hashing partners to retrace the full branch from the transaction leaf to the root as well as the block header (as does the complete block of course). That's how they know!

As username_2 [wrote](https://bitcoin.stackexchange.com/a/93373/5406) in another answer, most thin clients follow along with the network by synchronizing the block header chain. Since they do not parse the complete blocks, they do not keep track of the full ledger of bitcoin balances (the unspent transaction output set), and therefore cannot validate transactions. They can however perform basic validity checks on blocks such as whether they fulfill the current difficulty requirement, and whether the block header's content actually matches the given hash.


---

### Answer by username_2 on 2020-02-19. Score: 0

> how do A and B know the correct merkle path without needing the entire block?

Many light-clients will sync to the longest chain of headers, under the assumption that other nodes on the network will be checking the full content of those blocks for validity. (Consider: if every node was a light-client, miners could include invalid transactions in blocks, and none of the light-clients would know it!)

By requesting the intermediate states of the merkle tree from a node that has the full block, a light-client can verify that a transaction the user is interested in is indeed included in a block that is part of the longest chain, in a more efficient manner than validating the entirety of the block themselves (the caveat being the assumption of validity mentioned above).

> Do they need a centralized provider that processes the blocks to calculate these for them? Is it possible to do in a decentralized way?

This entirely depends on the implementation. Some light-wallets might just call back to a certain server, operated by the wallet's developers, for example. Other light-clients might attempt to pull this information from random nodes on the network. Some are even built to connect to your own node.

Ultimately, the highest level of certainty will come from running a fully-validating node yourself (ie, a full node). As bitcoiners like to say: don't trust, verify.


---

