Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20130721155513.GA3107@vps7135.xlshosting.net>
References: <C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com>
	<CANEZrP0_H9+prDSF92q8a4QzP=fzDM6cTDv0+KcfV9NF9thkmw@mail.gmail.com>
	<3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
	<CANEZrP2jmWkDbpJEm0vd2CKF-prFNbz_ZeNJfDWtSCKb8k5ZXA@mail.gmail.com>
	<2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>
	<CANEZrP0McSrVzwv=-qimPyX41EEDmyQdYW5QjPr_i+KWyJZSZw@mail.gmail.com>
	<2F20A509-13A9-4C84-86D7-A15C21BACD53@include7.ch>
	<CANEZrP2yQvmvwP_ZULdS2i+X6L9MeZ+DfidiuZPD2EHwLsN2MA@mail.gmail.com>
	<2A1C412D-414E-4C41-8E20-F0D21F801328@grabhive.com>
	<CANEZrP12V_5Ak0f91RsMziuqXysde102rGeSko=qPBjefy3AeA@mail.gmail.com>
	<20130721155513.GA3107@vps7135.xlshosting.net>
Date: Sun, 21 Jul 2013 19:20:18 +0200
Message-ID: <CANEZrP03Dh8kvAg+VJEC-4_8ibgix-bTQ1JqvZMxUvUpcr-6aw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b4728b423af1204e208c658
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Jonas Schnelli <jonas.schnelli@include7.ch>
Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework
Precedence: list

--047d7b4728b423af1204e208c658
Content-Type: text/plain; charset=UTF-8

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

--047d7b4728b423af1204e208c658
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Actually bitcoinj typically doesn&#39;t download all the hea=
ders (just from the last checkpoint) and it throws away headers that are ve=
ry old. By now there&#39;s quite a lot of difference in how they manage thi=
ngs and I guess it will diverge from bitcoind even more in future. For inst=
ance we&#39;re going to start only storing relevant outputs in the wallet a=
nd doing other things to try and save memory. Some people managed to get th=
emselves wallets that don&#39;t actually fit in ram :(</p>

<div class=3D"gmail_quote">On 21 Jul 2013 17:55, &quot;Pieter Wuille&quot; =
&lt;<a href=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&=
gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn wrote:<br>
&gt; I think that&#39;s a great approach. Here is the patch Satoshi sent me=
 back in<br>
&gt; 2010. All the code has changed since but it can be a source of inspira=
tion.<br>
&gt;<br>
&gt; &gt;From Satoshi:<br>
&gt;<br>
&gt; *The simplified payment verification in the paper imagined you would<b=
r>
&gt; receive transactions directly, as with sending to IP address which nob=
ody<br>
&gt; uses, or a node would index all transactions by public key and you cou=
ld<br>
&gt; download them like downloading mail from a mail server.<br>
<br>
I&#39;m currently working on headers-first sync, which I believe is general=
ly<br>
very useful (it fixes tons of edge-cases block synchronization currently<br=
>
experiences), but it&#39;s also a first step towards SPV mode.<br>
<br>
So headers-first sync means you first synchronize just the headers, and the=
n,<br>
when you already know (or have strong evidence for a guess on) the best cha=
in,<br>
start requesting blocks along that best chain - potentially in parallel fro=
m<br>
different peers.<br>
<br>
SPV mode is basically headers-first sync, but never do the full block sync<=
br>
step, and replace it with a bloom/birthday/...-based fetching of blocks<br>
interesting to the associated wallets. In SPV you&#39;ll also need to disab=
le<br>
the mempool though, and there will be more small changes, but I think<br>
the separate headers-sync phase will be most of the work.<br>
<br>
--<br>
Pieter<br>
<br>
</blockquote></div>

--047d7b4728b423af1204e208c658--