3

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?

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.
  • So how can a client know which block to request? – summerbulb May 21 '13 at 7:02
  • Why doesn't my client support the getdata method? Is it a new one? – Steven Roose May 21 '13 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. – Pieter Wuille May 21 '13 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. – Pieter Wuille May 21 '13 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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