1

is there a way for a non-full node (ie a node which does not contain the full blockchain) to know when it has received all transactions associated with an address? i understand that it is possible for a non-full node to tell if it has been fed an invalid transaction - the node can check that the transaction hash exists in the pruned merkle tree for the specified block, then compute the merkle root for that tree and check it exists in the block header. but i don't know of any checks to ensure that all transactions have been downloaded.

if transactions are not relayed by a malicious remote node then the target node will think it has less funds available than it really does.

i had thought that bloom filters might fix this problem, but i read in bip37:

Thus, a merkleblock message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

so it seems bip37 does not attempt to solve this issue.

Improve this question

1 Answer 1

Reset to default
2

Peers who don't use the whole blockchain are relying on at least one of their peers to send them transaction data when a transaction satisfies the bloom filter that the SPV (simplified payment verification) node has set. As such, SPV nodes have to be careful about which peers they connect to, and that they have a variety of peers. I believe some implementations of SPV nodes only connect to a set of defined, or are at least configurable to only connect to a strict set of peers.

Read how the bitcoinj (SPV node implementation) creator describes its security here:

Because bitcoinj apps do not accept incoming connections, the peers you talk to are always randomly selected at startup (based on DNS seeds today). So it can be difficult for an attacker to control your connectivity like that. For this reason, the number of peers that have announced a transaction is exposed in the TransactionConfidence object and you can listen on that to learn when new peers have announced a transaction. Once most of your peers have announced, you can be fairly sure that the transaction is propagating its way across the network and is very likely to be valid.

Improve this answer
1
  • 1
    interesting. if i understand it correctly, dns-seeds just pick randomly from the available client ip addresses? if so then i think a malicious network admin (eg at the isp level) could limit your connection down to only unreliable peers who then omit txs. its far fetched, i know, but still...
    – mulllhausen
    Mar 29, 2015 at 5:05

Your Answer

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

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