<p>There is no way in the current P2P protocol to request a historical (=confirmed) transaction, without requesting the block it is in. Supporting that would require the peer to have a full index of all transactions ever, which isn't necessary for normal operation.</p>

<p>To request a transaction, you will either:</p>

<ul>
<li>Use <code>getdata MSG_TX &lt;txid&gt;</code> to request a memory pool or recently relayed transaction. In this case, no block information exists.</li>
<li>Use <code>getdata MSG_BLOCK &lt;blkid&gt;</code> to request a full block, in which case you get the block with it, and need to check the full merkle tree anyway.</li>
<li>Use <code>getdata MSG_FILTERED_BLOCK &lt;blkid&gt;</code> to request a filtered block (see BIP37), in which case you can check the partial merkle tree to verify the transaction is indeed part of the block.</li>
</ul>

CC BY-SA 3.0
2013-05-21T07:02:53.373Z
So how can a client know which block to request?
summerbulb
CC BY-SA 3.0
2013-05-21T11:08:14.310Z
Why doesn't my client support the `getdata` method? Is it a new one?
Steven Roose
CC BY-SA 3.0
2013-05-21T17:57:07.733Z
@summerbulb You requests successive blocks as part of the synchronizing process (you don't fetch blocks in order to fetch specific transactions, they just happen to be part of those blocks), using a `getblocks`/`inv`/`getdata`/`block` cycle.
Pieter Wuille
CC BY-SA 3.0
2013-05-21T17:58:16.580Z
@StevenRoose `getdata` is a P2P message, not an RPC call. You can just the `getblock` and `getblockhash` RPC commands to request blocks from the database.
Pieter Wuille
CC BY-SA 3.0
2013-05-20T19:03:40.337Z
2013-05-20T19:03:40.337Z
Pieter Wuille
<p>When the Bitcoin client receives a transaction, it checks if the transaction is confirmed. This is done by verifying that the transaction hashes correctly, in the merkle tree, to the merkle root in a block.</p>

<p>How does the client know which block holds the merkle root of the transaction?</p>

<p>After finding the correct block, how is the merkle branch acquired?</p>

<transactions><blockchain><verification><merkle-tree>
How does a client get the merkle branch of a transaction?
summerbulb
# How does a client get the merkle branch of a transaction?

(Asked by: username_0 on 2013-05-20)

When the Bitcoin client receives a transaction, it checks if the transaction is confirmed. This is done by verifying that the transaction hashes correctly, in the merkle tree, to the merkle root in a block.

How does the client know which block holds the merkle root of the transaction?

After finding the correct block, how is the merkle branch acquired?

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


---

## 1 answers

### Answer by username_1 on 2013-05-20. Score: 3 | Accepted answer

There is no way in the current P2P protocol to request a historical (=confirmed) transaction, without requesting the block it is in. Supporting that would require the peer to have a full index of all transactions ever, which isn't necessary for normal operation.

To request a transaction, you will either:

* Use `getdata MSG_TX <txid>` to request a memory pool or recently relayed transaction. In this case, no block information exists.
* Use `getdata MSG_BLOCK <blkid>` to request a full block, in which case you get the block with it, and need to check the full merkle tree anyway.
* Use `getdata MSG_FILTERED_BLOCK <blkid>` to request a filtered block (see BIP37), in which case you can check the partial merkle tree to verify the transaction is indeed part of the block.

> **Comments:**
> **username_0**: So how can a client know which block to request?  
> **username_2**: Why doesn't my client support the `getdata` method? Is it a new one?  
> **username_1**: @username_0 You requests successive blocks as part of the synchronizing process (you don't fetch blocks in order to fetch specific transactions, they just happen to be part of those blocks), using a `getblocks`/`inv`/`getdata`/`block` cycle.  
> **username_1**: @username_2 `getdata` is a P2P message, not an RPC call. You can just the `getblock` and `getblockhash` RPC commands to request blocks from the database.  

---

