Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.175 as permitted sender)
	client-ip=209.85.216.175; envelope-from=tier.nolan@gmail.com;
	helo=mail-qc0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgT_9tXCxOHX_sN0wa=GRMn5seu3-o1UdiLjvbivFr46_w@mail.gmail.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>
Date: Mon, 7 Apr 2014 20:13:07 +0100
Message-ID: <CAE-z3OWpw-uvjvRD-DymjtRjMK=zBF_B46do8dAQQcbWu6oyXQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c1e0545a85e604f678a838
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
Precedence: list

--001a11c1e0545a85e604f678a838
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>

A range seems like a great compromise.  Putting it in the address is also a
pretty cool.

If light nodes selected a random contiguous 1GB of the block-chain, then
they could handle most of the download overhead, rather than the full nodes.

Another way to do it would be to have something like a routing table.  If a
node is queried for a block, it can reply with the IP of a node with that
block instead of sending the block.

One problem is that it means that light nodes have to accept incoming
connections.  Otherwise, it would have to be routed through the network.

--001a11c1e0545a85e604f678a838
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 7, 2014 at 8:03 PM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">A bitmap also means high overhead and&mdash;=
 if it&#39;s used to advertise<br>
non-contiguous blocks&mdash; poor locality, since blocks are fetched<br>
sequentially.<br></blockquote></div><br></div><div class=3D"gmail_extra">A =
range seems like a great compromise.&nbsp; Putting it in the address is als=
o a pretty cool.<br><br>If light nodes selected a random contiguous 1GB of =
the block-chain, then they could handle most of the download overhead, rath=
er than the full nodes.<br>
<br></div><div class=3D"gmail_extra">Another way to do it would be to have =
something like a routing table.&nbsp; If a node is queried for a block, it =
can reply with the IP of a node with that block instead of sending the bloc=
k.<br>
<br></div><div class=3D"gmail_extra">One problem is that it means that ligh=
t nodes have to accept incoming connections.&nbsp; Otherwise, it would have=
 to be routed through the network.<br></div></div>

--001a11c1e0545a85e604f678a838--