From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXFSA-0000a0-7s for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:43:34 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of hotmail.ca designates 65.55.111.149 as permitted sender) client-ip=65.55.111.149; envelope-from=pmlyon@hotmail.ca; helo=blu0-omc4-s10.blu0.hotmail.com; Received: from blu0-omc4-s10.blu0.hotmail.com ([65.55.111.149]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WXFS8-0001BE-As for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:43:34 +0000 Received: from BLU170-W124 ([65.55.111.136]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Apr 2014 12:30:55 -0700 X-TMN: [MKi9hBMkV86xbtJ6v3Oc9ikaw0oJRT4j] X-Originating-Email: [pmlyon@hotmail.ca] Message-ID: Content-Type: multipart/alternative; boundary="_398e6eeb-193a-4f95-bd4d-c49eb281e83e_" From: Paul Lyon To: Tamas Blummer , Gregory Maxwell Date: Mon, 7 Apr 2014 16:30:54 -0300 Importance: Normal In-Reply-To: <8222EAFD-813E-4046-A751-FD3D04FF6764@bitsofproof.com> References: , <5342C833.5030906@gmail.com>, , <6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net>, , <6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com>, , <8A6DEBA4-EA59-4BAE-95CF-C964C2DBB84B@bitsofproof.com>, , <8222EAFD-813E-4046-A751-FD3D04FF6764@bitsofproof.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2014 19:30:55.0207 (UTC) FILETIME=[E4F89770:01CF5297] X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.111.149 listed in list.dnswl.org] -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 (pmlyon[at]hotmail.ca) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXFS8-0001BE-As Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Why are we bleeding nodes? 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: Mon, 07 Apr 2014 19:43:34 -0000 --_398e6eeb-193a-4f95-bd4d-c49eb281e83e_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I hope I'm not thread-jacking here=2C apologies if so=2C but that's the app= roach I've taken with the node I'm working on. Headers can be downloaded and stored in any order=2C it'll make sense of wh= at the winning chain is. Blocks don't need to be downloaded in any particul= ar order and they don't need to be saved to disk=2C the UTXO is fully self-= contained. That way the concern of storing blocks for seeding (or not) is w= holly separated from syncing the UTXO. This allows me to do the initial blo= ckchain sync in ~6 hours when I use my SSD. I only need enough disk space t= o store the UTXO=2C and then whatever amount of block data the user would w= ant to store for the health of the network. This project is a bitcoin learning exercise for me=2C so I can only hope I = don't have any critical design flaws in there. :) From: tamas@bitsofproof.com Date: Mon=2C 7 Apr 2014 21:20:31 +0200 To: gmaxwell@gmail.com CC: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Why are we bleeding nodes? Once headers are loaded first there is no reason for sequential loading.=20 Validation has to be sequantial=2C but that step can be deferred until the = blocks before a point are loaded and continous. Tamas Blummerhttp://bitsofproof.com=0A= =0A= On 07.04.2014=2C at 21:03=2C Gregory Maxwell wrote:On = Mon=2C Apr 7=2C 2014 at 12:00 PM=2C Tamas Blummer w= rote: therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. A bitmap also means high overhead and=97 if it's used to advertise non-contiguous blocks=97 poor locality=2C since blocks are fetched sequentially. ---------------------------------------------------------------------------= ---=0A= Put Bad Developers to Shame=0A= Dominate Development with Jenkins Continuous Integration=0A= Continuously Automate Build=2C Test & Deployment =0A= Start a new project now. Try Jenkins in the cloud.=0A= http://p.sf.net/sfu/13600_Cloudbees _______________________________________________=0A= Bitcoin-development mailing list=0A= Bitcoin-development@lists.sourceforge.net=0A= https://lists.sourceforge.net/lists/listinfo/bitcoin-development = = --_398e6eeb-193a-4f95-bd4d-c49eb281e83e_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I hope I'm not thread-jacking he= re=2C apologies if so=2C but that's the approach I've taken with the node I= 'm working on.

Headers can be downloaded and stored in a= ny order=2C it'll make sense of what the winning chain is. Blocks don't nee= d to be downloaded in any particular order and they don't need to be saved = to disk=2C the UTXO is fully self-contained. That way the concern of storin= g blocks for seeding (or not) is wholly separated from syncing the UTXO. Th= is allows me to do the initial blockchain sync in ~6 hours when I use my SS= D. I only need enough disk space to store the UTXO=2C and then whatever amo= unt of block data the user would want to store for the health of the networ= k.

This project is a bitcoin learning exercise for= me=2C so I can only hope I don't have any critical design flaws in there. = :)

From: tamas@bitsofproof.com
Date:= Mon=2C 7 Apr 2014 21:20:31 +0200
To: gmaxwell@gmail.com
CC: bitcoin-= development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why= are we bleeding nodes?


Once headers are loa= ded first there is no reason for sequential loading. =3B

=
Validation has to be sequantial=2C but that step can be deferred= until the blocks before a point are loaded and continous.

=0A=

On Mon=2C Apr 7= =2C 2014 at 12:00 PM=2C Tamas Blummer <=3Btamas@bitsofproof.com>=3B wrote:
therefore I guess it is more handy to return some bitmap of pruned/full<= br>blocks than ranges.

A bitmap also means high overhea= d and=97 if it's used to advertise
non-contiguous blocks=97 poor localit= y=2C since blocks are fetched
sequentially.


---------------------------------------------------------------------= ---------=0A= Put Bad Developers to Shame=0A= Dominate Development with Jenkins Continuous Integration=0A= Continuously Automate Build=2C Test &=3B Deployment =0A= Start a new project now. Try Jenkins in the cloud.=0A= http://p.sf.net/sfu/13600_Cloudbees
____________________________________= ___________=0A= Bitcoin-development mailing list=0A= Bitcoin-development@lists.sourceforge.net=0A= https://lists.sourceforge.net/lists/listinfo/bitcoin-development
= --_398e6eeb-193a-4f95-bd4d-c49eb281e83e_--