Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXFLe-0003V1-A9 for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:36:50 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WXFLc-00017H-B0 for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:36:50 +0000 Received: from [37.143.74.116] (helo=[192.168.0.102]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WXFLW-0001gU-6j; Mon, 07 Apr 2014 21:36:42 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_E0663448-6141-420E-B151-03CA758B59F0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tamas Blummer In-Reply-To: <5342F8C0.60500@monetize.io> Date: Mon, 7 Apr 2014 21:36:56 +0200 Message-Id: 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> <5342F8C0.60500@monetize.io> To: Mark Friedenbach X-Mailer: Apple Mail (2.1874) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396899408; 69cf347c; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXFLc-00017H-B0 Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:36:50 -0000 --Apple-Mail=_E0663448-6141-420E-B151-03CA758B59F0 Content-Type: multipart/alternative; boundary="Apple-Mail=_471DBE0E-72E5-40FB-B778-A1E3B6A00FCB" --Apple-Mail=_471DBE0E-72E5-40FB-B778-A1E3B6A00FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You have the trunk defined by the headers. Once a range from genesis to = block n is fully downloaded, you may validate upto block n. Furthermore after validation you can = prune transactions spent until block n. You would approach the highest block with validation and stop pruning = say 100 blocks before it, to leave room for reorgs. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 21:13, Mark Friedenbach wrote: >=20 >=20 > On 04/07/2014 12:20 PM, Tamas Blummer wrote: >> Validation has to be sequantial, but that step can be deferred until = the >> blocks before a point are loaded and continous. >=20 > And how do you find those blocks? >=20 > I have a suggestion: have nodes advertise which range of full blocks > they possess, then you can perform synchronization from the adversed = ranges! >=20 > = --------------------------------------------------------------------------= ---- > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment=20 > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --Apple-Mail=_471DBE0E-72E5-40FB-B778-A1E3B6A00FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
You have the trunk defined by the headers. Once = a range from genesis to block n is fully downloaded,
you may = validate upto block n. Furthermore after validation you can prune = transactions spent until block n.

You would = approach the highest block with validation and stop pruning say 100 = blocks before it, to leave room for reorgs.


On 07.04.2014, at 21:13, Mark Friedenbach <mark@monetize.io> = wrote:



On 04/07/2014 12:20 PM, Tamas Blummer = wrote:
Validation has to be sequantial, but = that step can be deferred until the
blocks before a point are loaded = and continous.

And how do you find those = blocks?

I have a suggestion: have nodes advertise which range of = full blocks
they possess, then you can perform synchronization from = the adversed = ranges!

-----------------------------------------------------------= -------------------
Put Bad Developers to Shame
Dominate = Development with Jenkins Continuous Integration
Continuously Automate = Build, Test & Deployment
Start a new project now. Try Jenkins in = the cloud.
http://p.sf.net/sfu/13600_Clo= udbees
_______________________________________________
Bitcoin-d= evelopment mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development


= = --Apple-Mail=_471DBE0E-72E5-40FB-B778-A1E3B6A00FCB-- --Apple-Mail=_E0663448-6141-420E-B151-03CA758B59F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTQv5YAAoJEPZykcUXcTkcstsIAMlnrD9GvaEOnSqUZVodkNth 67ivZJa79y7c96iYXNZK/fCKQTaAN4FpZoo712h+x900+ToyUWnCw1DN2MoGuRlp bVhNnJU0SCwux73Lb7UdQV34E36KyJEcN+w6cxnhPbsUmwOzQJpiwbvwhJMKhYTC 6B/Gdgy5M16HuLTe5CYlg956sZFOukVu5345va4lx3tYQgH68lgBuhMp5/iZx5HD bYlNa/PIbH0lpl+3sJ4eyyJSh+F7WFRCdCUHX4HkzJca/G7lQ2gFtEfvcyJxCO17 XFGzjkx8pa0AdSPTo0LYPAzz9CWknDdn+r68zJ05p0PLVv3yXdYinxrYLkl/jgg= =9PUD -----END PGP SIGNATURE----- --Apple-Mail=_E0663448-6141-420E-B151-03CA758B59F0--