5

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?

1 Answer 1

3

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.
4
  • So how can a client know which block to request?
    – summerbulb
    Commented May 21, 2013 at 7:02
  • Why doesn't my client support the getdata method? Is it a new one? Commented May 21, 2013 at 11:08
  • @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. Commented May 21, 2013 at 17:57
  • @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. Commented May 21, 2013 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.