summaryrefslogtreecommitdiff
path: root/30/c52a26f3e493e9493e333e85ffcaf3d16fca38
blob: 0cbadde0987ae50631caeb9fb79e94ae55b04621 (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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B300A9CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 18:15:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
	[209.85.213.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4811B1B7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 18:15:49 +0000 (UTC)
Received: by igfj19 with SMTP id j19so62576306igf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 11:15:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=xxrGbEJfX69+YDTCvCuoTaxGsjUqWbpylQvtmZlCwWI=;
	b=lAhQ1EB1mrMH7Tm5bGHIpHWcAwUo8wGiAuSoN22HkW/hjelUqAswWHSunr81VHo8DJ
	iTZq9iuFKyoLRlaOUhkNYqLHkwkgtN8lrVXbGHcAJcv+I3NS2ZXuAgzTvTGBR0n3iuA9
	bYmDzdIAtVIVJwRNnfzjUYHREcjEImPap48op2D/bDhLerIcSxAz+wqDSLXak/wskUCc
	bh/aWtjnf2AS6TCvd9Wo5V26GKRg8Y0tLiWkFpF6u5z9saKyDuaggoluj74OsWhny+Ua
	jRgwGBKN/2jpOZEYCU6NpJR/Sm8oyiVc6D6KMCpOAoRrJrHCbkUOBODj99hZZnnXPT+V
	YbLw==
X-Received: by 10.50.153.112 with SMTP id vf16mr16213891igb.79.1440440148723; 
	Mon, 24 Aug 2015 11:15:48 -0700 (PDT)
MIME-Version: 1.0
References: <55D6AD19.10305@mattcorallo.com>
	<20150824152955.GA6924@amethyst.visucore.com>
	<55DB566F.1010702@mattcorallo.com> <20150824180044.GA5729@muck>
	<55DB5D49.4050800@mattcorallo.com>
In-Reply-To: <55DB5D49.4050800@mattcorallo.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Mon, 24 Aug 2015 18:15:39 +0000
Message-ID: <CABr1YTceCUPSwUe9M2zUSXcB1qvtmq5PP6=ZBzaw19=VgO79GQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e01536c1062914e051e129b5e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2015 18:15:49 -0000

--089e01536c1062914e051e129b5e
Content-Type: text/plain; charset=UTF-8

It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
again, perhaps it would be smarter to ditch the whole bloom filter thing in
favor of an actual client/server architecture with proper authentication
and access controls.

The RPC was supposed to be this client/server architecture...but in
practice it sucks so bad for doing anything beyond administering a node
instance you fully control yourself that I eschewed it entirely in my
wallet design.

On Mon, Aug 24, 2015, 11:07 AM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP 111 was assigned, pull request (with the proposed changes) available
> at https://github.com/bitcoin/bips/pull/183
>
> Matt
>
> On 08/24/15 18:00, Peter Todd wrote:
> > On Mon, Aug 24, 2015 at 05:37:51PM +0000, Matt Corallo via bitcoin-dev
> wrote:
> >> Its more of a statement of "in the future, we expect things to happen
> >> which would make this an interesting thing to do, so we state here that
> >> it is not against spec to do so". Could reword it as "NODE_BLOOM is
> >> distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but
> >> not NODE_NETWORK (though there is little reason to do so now, some
> >> proposals may make this more useful in the future)"?
> >
> > ACK
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--089e01536c1062914e051e129b5e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">It would be very useful to not only be able to switch filter=
ing on and off globally...but to be able to switch on a per-connection basi=
s. But then again, perhaps it would be smarter to ditch the whole bloom fil=
ter thing in favor of an actual client/server architecture with proper auth=
entication and access controls.</p>
<p dir=3D"ltr">The RPC was supposed to be this client/server architecture..=
.but in practice it sucks so bad for doing anything beyond administering a =
node instance you fully control yourself that I eschewed it entirely in my =
wallet design.<br>
</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 24, 2015, 11:07=
 AM=C2=A0Matt Corallo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">BIP 111 was assigned, pull reques=
t (with the proposed changes) available<br>
at <a href=3D"https://github.com/bitcoin/bips/pull/183" rel=3D"noreferrer" =
target=3D"_blank">https://github.com/bitcoin/bips/pull/183</a><br>
<br>
Matt<br>
<br>
On 08/24/15 18:00, Peter Todd wrote:<br>
&gt; On Mon, Aug 24, 2015 at 05:37:51PM +0000, Matt Corallo via bitcoin-dev=
 wrote:<br>
&gt;&gt; Its more of a statement of &quot;in the future, we expect things t=
o happen<br>
&gt;&gt; which would make this an interesting thing to do, so we state here=
 that<br>
&gt;&gt; it is not against spec to do so&quot;. Could reword it as &quot;NO=
DE_BLOOM is<br>
&gt;&gt; distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOO=
M but<br>
&gt;&gt; not NODE_NETWORK (though there is little reason to do so now, some=
<br>
&gt;&gt; proposals may make this more useful in the future)&quot;?<br>
&gt;<br>
&gt; ACK<br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--089e01536c1062914e051e129b5e--