Arbitrary access to already confirmed transactions

0

This link mentions that

"[getdata] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed..."

But can't an SPV node do the following to have the arbitrary access to a transaction T (I am assuming that the SPV node knows the block hash H of the block B containing T):

  1. set a bloom filter using filterload for T at some full node
  2. send getdata request with type MSG_FILTERED_BLOCK and block hash H
  3. then in response, the full node will generate two messages for the SPV node: first, a merkleblock of B; and second, the transaction T (as mentioned here and here)

Doesn't this mechanism actually gives arbitrary access to transactions?

archita

Posted 2018-11-29T22:46:53.940

Reputation: 13

That only works for a node which has transaction-index activated. If it doesn’t, it would not offer this service during the p2p handshake (version message indicates available services), and it would not be possible with this peer. – James C. – 2018-11-30T07:43:13.503

Answers

1

That is based on the minimum indexing required to run a full-node.

A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively.

Confirmed transaction are supplied as part of getdata request with blockhashes. Blocks are indexed by all full-nodes. (Since new block-headers must reference previous headers, even if they are branch-extending, vs strong-chain extending)

Correction(see comment below):

James C.

Posted 2018-11-29T22:46:53.940

Reputation: 2 183

1This is not correct. The approach suggested by OP (using BIP37) would work, but it is highly inefficient (it requires the full node scanning through the whole chain, but does not need an index). That's why of the reasons why BIP37 is being discouraged. – Pieter Wuille – 2018-11-30T09:08:19.203

Wow, an entire chain scan? Thanks for the correction - I would never have thought that this is done without index. – James C. – 2018-11-30T09:16:32.130

1It's no different from a full blockchain download, but while giving a filter first. The BIP37 bloom filter approach can't be easily sped up using an index anyway (as an index would inherently not have false positives, and thus leak a lot of privacy). See BIP157 for a more modern approach (which uses some precomputed data, but still not an index). – Pieter Wuille – 2018-11-30T17:06:43.563

Asked: 2018-11-29T22:46:53.940

Viewed: 44 times

Active: 2018-12-31T18:02:05.403