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?

Improve this question
1
  • 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.
    Commented Nov 30, 2018 at 7:43

1 Answer 1

Reset to default
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):

Improve this answer
3
  • 1
    This 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
    Commented Nov 30, 2018 at 9:08
  • Wow, an entire chain scan? Thanks for the correction - I would never have thought that this is done without index.
    – James C.
    Commented Nov 30, 2018 at 9:16
  • 1
    It'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
    Commented Nov 30, 2018 at 17:06

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.