summaryrefslogtreecommitdiff
path: root/d8/a21ac751835142bb3f2583f163aa1ca7f2d063
blob: cdc1a48886b00a2449b54f910db219e2d4fe4cfb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1WXEyq-0003Ui-7w
	for bitcoin-development@lists.sourceforge.net;
	Mon, 07 Apr 2014 19:13:16 +0000
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; 
Received: from mail-qc0-f175.google.com ([209.85.216.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WXEyp-0005PF-8o
	for bitcoin-development@lists.sourceforge.net;
	Mon, 07 Apr 2014 19:13:16 +0000
Received: by mail-qc0-f175.google.com with SMTP id e16so6868156qcx.20
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 07 Apr 2014 12:13:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.127.129 with SMTP id g1mr35722005qas.22.1396897987397;
	Mon, 07 Apr 2014 12:13:07 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Mon, 7 Apr 2014 12:13:07 -0700 (PDT)
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
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-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
	(tier.nolan[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WXEyp-0005PF-8o
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:13:16 -0000

--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--