Actually bitcoinj typically doesn't download all the headers (just from the last checkpoint) and it throws away headers that are very old. By now there's quite a lot of difference in how they manage things and I guess it will diverge from bitcoind even more in future. For instance we're going to start only storing relevant outputs in the wallet and doing other things to try and save memory. Some people managed to get themselves wallets that don't actually fit in ram :(
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn wrote:
> I think that's a great approach. Here is the patch Satoshi sent me back in
> 2010. All the code has changed since but it can be a source of inspiration.
>
> >From Satoshi:
>
> *The simplified payment verification in the paper imagined you would
> receive transactions directly, as with sending to IP address which nobody
> uses, or a node would index all transactions by public key and you could
> download them like downloading mail from a mail server.
I'm currently working on headers-first sync, which I believe is generally
very useful (it fixes tons of edge-cases block synchronization currently
experiences), but it's also a first step towards SPV mode.
So headers-first sync means you first synchronize just the headers, and then,
when you already know (or have strong evidence for a guess on) the best chain,
start requesting blocks along that best chain - potentially in parallel from
different peers.
SPV mode is basically headers-first sync, but never do the full block sync
step, and replace it with a bloom/birthday/...-based fetching of blocks
interesting to the associated wallets. In SPV you'll also need to disable
the mempool though, and there will be more small changes, but I think
the separate headers-sync phase will be most of the work.
--
Pieter