So you would want to show transactions which haven't been validated to the user before they are validated?
A transaction is not valid unless its has as its inputs references to the valid unspent outputs of prior transactions. You can't verify that the prior outputs exist and are unspent until you verify that they exist in a prior block AND they haven't been spent in a prior block.
A transaction is not valid unless its has as its inputs references to the valid unspent outputs of prior transactions. You can't verify that the prior outputs exist and are unspent until you verify that they exist in a prior block AND they haven't been spent in a prior block.
Until here, I don't agree, a client, as opposed to a full node, don't have to check if previous TxOut exists.
I believe he can just trust whatever blocks is sent to him if it belongs to the longest chain. (making a longer chain with fake transactions is too hard too keep up for very long)
But I agree that it is not acceptable for full node.
So you could start from the top down but it wouldn't be any faster, require less processing, or use less bandwidth. Also it is possible for malicious nodes to feed you shorter (less work) chains. They can't steal from you but it is a possible method to DOS the network. Clients are hardened against that by hardcoded checkpoints which limits the amount of resources that can be wasted. However working from the end of the chain backwards would remove that protection. If my node announces I my longest chain has a height of 9873972139821378923728932738912 blocks you are going to be doing a lot of bogus verifying.
True, I did not think about this case, this seems to respond to my question.
One thing that could be done is to make full nodes also act (optionally) as a SPV node while bootstrapping. So while you are building and verifying the blockchain in the background you would still have balances, tx notification, and the ability to spend as a SPV client very quickly (just need the blockheaders).
I thought that merkle filter were just filtering relayed transactions. After reading your response, I checked the BIP37 again, and noticed the "merkleblock" message which definitively offer a good solution.
I only heard, that opposite client (server) can give you complete different blockchain and you are unable to check it until you download whole blockchain to match first genesis block. On other side, you don't need to download all orphaned blocks.
Yes this is the DOS vector that DeathAndTaxes talk about, I did not anticipated that.
