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 <pmlyon@hotmail.ca>) 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: <BLU170-W124FFC4A5D42BC516663032A5680@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_398e6eeb-193a-4f95-bd4d-c49eb281e83e_"
From: Paul Lyon <pmlyon@hotmail.ca>
To: Tamas Blummer <tamas@bitsofproof.com>, Gregory Maxwell <gmaxwell@gmail.com>
Date: Mon, 7 Apr 2014 16:30:54 -0300
Importance: Normal
In-Reply-To: <8222EAFD-813E-4046-A751-FD3D04FF6764@bitsofproof.com>
References: <CANEZrP2rgiQHpekEpFviJ22QsiV+s-F2pqosaZOA5WrRtJx5pg@mail.gmail.com>,
	<5342C833.5030906@gmail.com>,
	<CAAS2fgTqBfEPXh2dfcL_ke6c0wfXw4qUM1rAYMkAHcAM6mYH+g@mail.gmail.com>,
	<6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net>,
	<CANEZrP1-9LpPw4WuY8bfsEG0OLoDECXTfQCoZsZ4tmOn2H7Omw@mail.gmail.com>,
	<6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com>,
	<CAAS2fgQaJ6P4Aj2A5Zox+CiGQK6jHvF1CkLH1R6xbadYhUXO2g@mail.gmail.com>,
	<8A6DEBA4-EA59-4BAE-95CF-C964C2DBB84B@bitsofproof.com>,
	<CAAS2fgT_9tXCxOHX_sN0wa=GRMn5seu3-o1UdiLjvbivFr46_w@mail.gmail.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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <gmaxwell@gmail.com> wrote:On =
Mon=2C Apr 7=2C 2014 at 12:00 PM=2C Tamas Blummer <tamas@bitsofproof.com> 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

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>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.<div><br></div><div>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.</div><div><br></div><div>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. =
:)<br><br><div><hr id=3D"stopSpelling">From: tamas@bitsofproof.com<br>Date:=
 Mon=2C 7 Apr 2014 21:20:31 +0200<br>To: gmaxwell@gmail.com<br>CC: bitcoin-=
development@lists.sourceforge.net<br>Subject: Re: [Bitcoin-development] Why=
 are we bleeding nodes?<br><br><meta http-equiv=3D"Content-Type" content=3D=
"text/html charset=3Dwindows-1252"><div><br></div><div>Once headers are loa=
ded first there is no reason for sequential loading.&nbsp=3B</div><div><br>=
</div><div>Validation has to be sequantial=2C but that step can be deferred=
 until the blocks before a point are loaded and continous.</div><br><div ap=
ple-content-edited=3D"true"><span style=3D"color: rgb(0=2C 0=2C 0)=3B font-=
family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant:=
 normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: no=
rmal=3B text-align: -webkit-auto=3B text-indent: 0px=3B text-transform: non=
e=3B white-space: normal=3B word-spacing: 0px=3B -webkit-text-stroke-width:=
 0px=3B orphans: 2=3B widows: 2=3B float: none=3B display: inline !importan=
t=3B">Tamas Blummer</span><span style=3D"color: rgb(0=2C 0=2C 0)=3B font-fa=
mily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: n=
ormal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norm=
al=3B orphans: auto=3B text-align: start=3B text-indent: 0px=3B text-transf=
orm: none=3B white-space: normal=3B widows: auto=3B word-spacing: 0px=3B -w=
ebkit-text-stroke-width: 0px=3B"><br style=3D"color: rgb(0=2C 0=2C 0)=3B fo=
nt-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-varia=
nt: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-height:=
 normal=3B text-align: -webkit-auto=3B text-indent: 0px=3B text-transform: =
none=3B white-space: normal=3B word-spacing: 0px=3B -webkit-text-stroke-wid=
th: 0px=3B orphans: 2=3B widows: 2=3B"><span style=3D"color: rgb(0=2C 0=2C =
0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B fo=
nt-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line=
-height: normal=3B text-align: -webkit-auto=3B text-indent: 0px=3B text-tra=
nsform: none=3B white-space: normal=3B word-spacing: 0px=3B -webkit-text-st=
roke-width: 0px=3B orphans: 2=3B widows: 2=3B float: none=3B display: inlin=
e !important=3B"><a href=3D"http://bitsofproof.com">http://bitsofproof.com<=
/a></span>=0A=
</span></div>=0A=
<br><div><div>On 07.04.2014=2C at 21:03=2C Gregory Maxwell &lt=3B<a href=3D=
"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt=3B wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><blockquote type=3D"cite">On Mon=2C Apr 7=
=2C 2014 at 12:00 PM=2C Tamas Blummer &lt=3B<a href=3D"mailto:tamas@bitsofp=
roof.com">tamas@bitsofproof.com</a>&gt=3B wrote:<br><blockquote type=3D"cit=
e">therefore I guess it is more handy to return some bitmap of pruned/full<=
br>blocks than ranges.<br></blockquote><br>A bitmap also means high overhea=
d and=97 if it's used to advertise<br>non-contiguous blocks=97 poor localit=
y=2C since blocks are fetched<br>sequentially.<br><br></blockquote></div><b=
r><br>---------------------------------------------------------------------=
---------=0A=
Put Bad Developers to Shame=0A=
Dominate Development with Jenkins Continuous Integration=0A=
Continuously Automate Build=2C Test &amp=3B Deployment =0A=
Start a new project now. Try Jenkins in the cloud.=0A=
http://p.sf.net/sfu/13600_Cloudbees<br>____________________________________=
___________=0A=
Bitcoin-development mailing list=0A=
Bitcoin-development@lists.sourceforge.net=0A=
https://lists.sourceforge.net/lists/listinfo/bitcoin-development</div></div=
> 		 	   		  </div></body>
</html>=

--_398e6eeb-193a-4f95-bd4d-c49eb281e83e_--