<p>All of this info is relevant to the operation of a light-wallet, which does not fully validate the blockchain, but instead validates the longest chain of block headers, and any transactions that are relevant to that light-wallet.</p>

<blockquote>
  <p>In what situation you want to validate a transaction is in a block.</p>
</blockquote>

<p>Simply: to ensure that a payment you have sent, received, or are otherwise interested in has been included in the Blockchain record. If someone pays you a huge sum of Bitcoin, you'll probably want to be sure that payment was actually legit!</p>

<blockquote>
  <p>How you find the block that the transaction could be in.</p>
</blockquote>

<p>The text you quoted from Mastering Bitcoin has the answer: a full-node peer will use your bloom filter to provide you with transaction info relevant to your wallet.</p>

<blockquote>
  <p>The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from that block.</p>
</blockquote>

<p>In order to verify the transaction is included, you will need to know which block it is in. This will allow your wallet to calculate the cryptographic proofs (using the merkle root that is in the header) that let it verify a transaction has occurred on the network in a trust-minimized way. </p>

<p>There is no way to similarly know that a transaction is included in the blockchain record, without knowing the specific block you need to check the cryptographic proofs against.</p>

<blockquote>
  <p>So you prove that it's recorded in the blockchain. I don't see how this means it's valid.</p>
</blockquote>

<p>Only valid transactions can be recorded in the blockchain history, though as a light-wallet, you are trusting that the network of full nodes is otherwise validating all blocks and transactions, to ensure no invalid data is included in the chain. As long as the full nodes are doing their job, invalid transactions cannot be included in the chain. Any miner that attempts to include an invalid transaction in a block, will see that block dropped by the network's nodes for being invalid. </p>

CC BY-SA 4.0
2019-02-17T21:48:37.130Z
2019-02-18T00:03:13.400Z
2019-02-18T00:03:13.400Z
chytrik
<p>So after getting <a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch09.asciidoc#merkle_tree_path" rel="nofollow noreferrer">here</a>, I have forgotten why you even want to validate a transaction is in a block, and how exactly this works. Wondering if one could explain</p>

<ol>
<li>In what situation you want to validate a transaction is in a block.</li>
<li>How you find the block that the transaction could be in.</li>
</ol>

<p>That link says here:</p>

<blockquote>
  <p>Consider, for example, an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter (see [bloom_filters]) on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a merkleblock message. The merkleblock message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 1 megabyte currently).</p>
</blockquote>

<p>I still don't understand why you need to verify the transaction is in the block, some questions that come up are:</p>

<ol>
<li>The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from <em>that</em> block.</li>
<li>So you prove that it's recorded in the blockchain. I don't see how this means it's valid.</li>
</ol>

<transactions><blockchain><merkle-tree>
When you need to validate a transaction is in a block
Lance Pollard
# When you need to validate a transaction is in a block

(Asked by: username_0 on 2019-02-17)

So after getting [here](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch09.asciidoc#merkle_tree_path), I have forgotten why you even want to validate a transaction is in a block, and how exactly this works. Wondering if one could explain

1. In what situation you want to validate a transaction is in a block.
2. How you find the block that the transaction could be in.

That link says here:

> Consider, for example, an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter (see [bloom\_filters]) on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a merkleblock message. The merkleblock message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 1 megabyte currently).

I still don't understand why you need to verify the transaction is in the block, some questions that come up are:

1. The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from *that* block.
2. So you prove that it's recorded in the blockchain. I don't see how this means it's valid.

**Tags:** transactions, blockchain, merkle-tree


---

## 1 answers

### Answer by username_1 on 2019-02-17. Score: 1 | Accepted answer

All of this info is relevant to the operation of a light-wallet, which does not fully validate the blockchain, but instead validates the longest chain of block headers, and any transactions that are relevant to that light-wallet.

> In what situation you want to validate a transaction is in a block.

Simply: to ensure that a payment you have sent, received, or are otherwise interested in has been included in the Blockchain record. If someone pays you a huge sum of Bitcoin, you'll probably want to be sure that payment was actually legit!

> How you find the block that the transaction could be in.

The text you quoted from Mastering Bitcoin has the answer: a full-node peer will use your bloom filter to provide you with transaction info relevant to your wallet.

> The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from that block.

In order to verify the transaction is included, you will need to know which block it is in. This will allow your wallet to calculate the cryptographic proofs (using the merkle root that is in the header) that let it verify a transaction has occurred on the network in a trust-minimized way.

There is no way to similarly know that a transaction is included in the blockchain record, without knowing the specific block you need to check the cryptographic proofs against.

> So you prove that it's recorded in the blockchain. I don't see how this means it's valid.

Only valid transactions can be recorded in the blockchain history, though as a light-wallet, you are trusting that the network of full nodes is otherwise validating all blocks and transactions, to ensure no invalid data is included in the chain. As long as the full nodes are doing their job, invalid transactions cannot be included in the chain. Any miner that attempts to include an invalid transaction in a block, will see that block dropped by the network's nodes for being invalid.


---

