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. =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 <=3B<a href=3D= "mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>>=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 <=3B<a href=3D"mailto:tamas@bitsofp= roof.com">tamas@bitsofproof.com</a>>=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 &=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_--