Re: [Bitcoin-development] Introducing BitcoinKit.framework

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

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 21 Jul 2013 17:55, "Pieter Wuille" <pieter.wuille@gmail.com> wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2342 bytes --]