From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V0xJ4-0004lw-1G for bitcoin-development@lists.sourceforge.net; Sun, 21 Jul 2013 17:20:26 +0000 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; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V0xJ2-0006fD-4F for bitcoin-development@lists.sourceforge.net; Sun, 21 Jul 2013 17:20:26 +0000 Received: by mail-oa0-f50.google.com with SMTP id k7so8193630oag.9 for ; Sun, 21 Jul 2013 10:20:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.133.44 with SMTP id oz12mr23908490oeb.62.1374427218683; Sun, 21 Jul 2013 10:20:18 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Sun, 21 Jul 2013 10:20:18 -0700 (PDT) Received: by 10.76.23.36 with HTTP; Sun, 21 Jul 2013 10:20:18 -0700 (PDT) In-Reply-To: <20130721155513.GA3107@vps7135.xlshosting.net> References: <3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch> <2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch> <2F20A509-13A9-4C84-86D7-A15C21BACD53@include7.ch> <2A1C412D-414E-4C41-8E20-F0D21F801328@grabhive.com> <20130721155513.GA3107@vps7135.xlshosting.net> Date: Sun, 21 Jul 2013 19:20:18 +0200 X-Google-Sender-Auth: MFL2nSs0sAuWqQEnuecWOHxJF8U Message-ID: From: Mike Hearn To: Pieter Wuille Content-Type: multipart/alternative; boundary=047d7b4728b423af1204e208c658 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V0xJ2-0006fD-4F Cc: Bitcoin Dev , Jonas Schnelli Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 17:20:26 -0000 --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" 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

Actually bitcoinj typically doesn't download all the hea= ders (just from the last checkpoint) and it throws away headers that are ve= ry old. By now there'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'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't actually fit in ram :(

On 21 Jul 2013 17:55, "Pieter Wuille" = <pieter.wuille@gmail.com&= gt; 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 inspira= tion.
>
> >From Satoshi:
>
> *The simplified payment verification in the paper imagined you would > receive transactions directly, as with sending to IP address which nob= ody
> uses, or a node would index all transactions by public key and you cou= ld
> download them like downloading mail from a mail server.

I'm currently working on headers-first sync, which I believe is general= ly
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 the= n,
when you already know (or have strong evidence for a guess on) the best cha= in,
start requesting blocks along that best chain - potentially in parallel fro= m
different peers.

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
interesting to the associated wallets. In SPV you'll also need to disab= le
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--