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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WmN4u-0002m3-37
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 12:54:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WmN4t-0002eV-2t
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 12:54:04 +0000
Received: by mail-oa0-f51.google.com with SMTP id n16so6142629oag.24
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 May 2014 05:53:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.33.131 with SMTP id r3mr36106649obi.40.1400504037640;
Mon, 19 May 2014 05:53:57 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 19 May 2014 05:53:57 -0700 (PDT)
In-Reply-To: <CA+s+GJCzks9RRi8HgFbPJ+zmuona26QCpYX8Eax+Qg6WmDd2fQ@mail.gmail.com>
References: <CA+8=xu+GPykmKdAjxLdRA3QoCPR8azervT9uO-GVraNowAb49g@mail.gmail.com>
<5379CE4D.5040100@gmail.com>
<CA+s+GJCzks9RRi8HgFbPJ+zmuona26QCpYX8Eax+Qg6WmDd2fQ@mail.gmail.com>
Date: Mon, 19 May 2014 14:53:57 +0200
X-Google-Sender-Auth: uSSvrRSpib9h0kUW0VRlwwbHWBM
Message-ID: <CANEZrP01qyMiCddOEo3Kpoj4P1JKocjEPUL-Veh0toECWMUMxQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2d26cab917804f9c0414a
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WmN4t-0002eV-2t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] About the small number of bitcoin 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, 19 May 2014 12:54:04 -0000
--001a11c2d26cab917804f9c0414a
Content-Type: text/plain; charset=UTF-8
>
> (sure - there are tricks to limit rates anyway, like the script in
> contrib/qos, but to have it generally available the block download
> needs to be more robust first)
One thing we could consider as a short term solution (if headers
first+parallel downloading will take a while, which seems plausible) is to
add a service bit that says "I have chain data and am willing to Bloom
filter it for you, but I won't serve full block data", and then just
exclude all of those from the chain download logic. It should not be a deep
change to the code headers first is impacting, and would allow home users
who may have no tolerance for block chain uploads at all to still take part
and offer useful services to the network.
I know Pieter likes the idea of an "archival node" service bit, or
something like that. I'd been thinking that the stored chain height value
would be better, but perhaps we need to divorce "I have CPU and can filter"
from "I have bandwidth and can serve" more vigorously.
--001a11c2d26cab917804f9c0414a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">(sure - there are tricks to limi=
t rates anyway, like the script in<br>
</div>
contrib/qos, but to have it generally available the block download<br>
needs to be more robust first)</blockquote><div><br></div><div>One thing we=
could consider as a short term solution (if headers first+parallel downloa=
ding will take a while, which seems plausible) is to add a service bit that=
says "I have chain data and am willing to Bloom filter it for you, bu=
t I won't serve full block data", and then just exclude all of tho=
se from the chain download logic. It should not be a deep change to the cod=
e headers first is impacting, and would allow home users who may have no to=
lerance for block chain uploads at all to still take part and offer useful =
services to the network.<br>
</div><div><br></div><div>I know Pieter likes the idea of an "archival=
node" service bit, or something like that. I'd been thinking that=
the stored chain height value would be better, but perhaps we need to divo=
rce "I have CPU and can filter" from "I have bandwidth and c=
an serve" more vigorously.</div>
</div></div></div>
--001a11c2d26cab917804f9c0414a--
|
