Ugh, yeah the documentation for anything related to Bitcoin is terrible. Originally it didn't use bloom filters, they're a new thing as of Bitcoin client version 0.8 and above.
> the descriptions I've seen of SPV allowed the client to only store a subset of the data, but still needed to download everything at least once in order to have any semblance of trust in the data it was seeing.
With bloom filters you don't need to bother with all of that. The headers of the blocks are separate from the transaction data itself (that's in the merkle tree), so the SPV client can download all of the headers up to the current date and verify their difficulty in a few seconds. As the wallet gains addresses it sets bloom filters with it's peers, when they announce a new block on the network they send the SPV client the block header and also a trimmed merkle tree with only the transactions relevant to the client left in it. The SPV client can verify that the transaction is in the block by following up the tree to the block header, without ever needing to download the entire thing.
Privacy is gained by setting false positives in the filter, the more junk results the less likely it in the peer can discover what the SPV client is really interested in and what is being discarded. The SPV client ultimately doesn't need to store anything but the outputs that are unspent, and transaction history if this is required. There's no trust in the peers as at worst they can withhold blocks from us that contain transactional data, to counter this we can connect to multiple peers with the same filters set and compare the difference.
> However, I would then argue that it should be a really big priority to make people understand that this feature exists, is deployed, is practical, and is secure, as otherwise people are going to keep going about their lives as I have assuming this is all impossible with the current implementation of Bitcoin
This is a problem really, we have lots of awesome crypto features but everybody just insists on using solutions that don't scale like blockchain.info. The original whitepaper describes some of the scaling features but doesn't mention bloom filters specifically I don't think.
> the descriptions I've seen of SPV allowed the client to only store a subset of the data, but still needed to download everything at least once in order to have any semblance of trust in the data it was seeing.
With bloom filters you don't need to bother with all of that. The headers of the blocks are separate from the transaction data itself (that's in the merkle tree), so the SPV client can download all of the headers up to the current date and verify their difficulty in a few seconds. As the wallet gains addresses it sets bloom filters with it's peers, when they announce a new block on the network they send the SPV client the block header and also a trimmed merkle tree with only the transactions relevant to the client left in it. The SPV client can verify that the transaction is in the block by following up the tree to the block header, without ever needing to download the entire thing.
Privacy is gained by setting false positives in the filter, the more junk results the less likely it in the peer can discover what the SPV client is really interested in and what is being discarded. The SPV client ultimately doesn't need to store anything but the outputs that are unspent, and transaction history if this is required. There's no trust in the peers as at worst they can withhold blocks from us that contain transactional data, to counter this we can connect to multiple peers with the same filters set and compare the difference.
> However, I would then argue that it should be a really big priority to make people understand that this feature exists, is deployed, is practical, and is secure, as otherwise people are going to keep going about their lives as I have assuming this is all impossible with the current implementation of Bitcoin
This is a problem really, we have lots of awesome crypto features but everybody just insists on using solutions that don't scale like blockchain.info. The original whitepaper describes some of the scaling features but doesn't mention bloom filters specifically I don't think.