3
1
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:
getdata MSG_TX <txid> to request a memory pool or recently relayed transaction. In this case, no block information exists.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.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 – 2013-05-21T07:02:53.373
Why doesn't my client support the
getdatamethod? Is it a new one? – Steven Roose – 2013-05-21T11:08:14.310@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/blockcycle. – Pieter Wuille – 2013-05-21T17:57:07.733@StevenRoose
getdatais a P2P message, not an RPC call. You can just thegetblockandgetblockhashRPC commands to request blocks from the database. – Pieter Wuille – 2013-05-21T17:58:16.580