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
|
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 96CE9BC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 17:59:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FBAB153
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 17:59:05 +0000 (UTC)
Received: by iodb91 with SMTP id b91so157474996iod.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 10:59:04 -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=aKy5euCLnMm0o6RB1KRS+M+/opy8qHodpCMac8RUJok=;
b=Nc1bU8dAsSQfxTy5JP5m/QNPaK4R/yvR2MmRQtJxB2i3o5zD2QxbQc59uX5RAJdQve
5yliTgoTUH55Bzz24RnZCqDb6mXLIBGzsh3bbbvLapPUYdvCoRkus3f56v4iywFRtcne
gzv6nW1wc5fN8dM0fwtEIEJzQzD0CMkwQE9uJUDLoojBaN7WNQDdlwRnPhojMXpt3R0g
n1aXsr7t54nXEl2JzrLln2ESExwUSU/PHlXl/zAWh9g4S2NsDgwdf08w4CWqAjjjLywf
Lls0vIig1+/nAXAanhj5tLTYXRKix6v5/zFp1HhVXGyfOsLZq2HCO1bW7K4jOS0xSvJX
wdbw==
X-Received: by 10.107.129.160 with SMTP id l32mr18295552ioi.158.1440439144601;
Mon, 24 Aug 2015 10:59:04 -0700 (PDT)
MIME-Version: 1.0
References: <55D6AD19.10305@mattcorallo.com>
<20150824152955.GA6924@amethyst.visucore.com>
<55DB566F.1010702@mattcorallo.com>
<20150824174141.GA7441@amethyst.visucore.com>
In-Reply-To: <20150824174141.GA7441@amethyst.visucore.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Mon, 24 Aug 2015 17:58:55 +0000
Message-ID: <CABr1YTfyN+u8NS_KVx8Jr8EpQe-8ZRCnTzUfX75ULfJRZNm6VA@mail.gmail.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>,
Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=001a113ec3a688e183051e125fbd
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 17:59:05 -0000
--001a113ec3a688e183051e125fbd
Content-Type: text/plain; charset=UTF-8
When I was working on mSIGNA I became a little torn on the whole filtering
mechanism. I fully support connection filtering...but in practice always
run my own full node instances to connect to due to the three fatal flaws:
1) no mechanism for short proofs of tx nonexclusion, txout unspentness,
block validity, nor the ability to find the first instance of the use of a
scriptPubKey without full blockchain scanning, 2) poor privacy, 3) lack of
incentives to run servers.
I always felt that BIP37 was necessarily a step towards a client/server
architecture.
Having said that, I have found the filter mechanism useful, if only because
no "special" server is required. However, in practice I'd rather make the
distinction between trustless peers and a client/server model more explicit.
On Mon, Aug 24, 2015, 10:41 AM Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Aug 24, 2015 at 05:37:51PM +0000, Matt Corallo 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)"?
>
> Yes, it makes sense to not explicitly exclude it.
> Looks good to me.
>
> Wladimir
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113ec3a688e183051e125fbd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">When I was working on mSIGNA I became a little torn on the w=
hole filtering mechanism. I fully support connection filtering...but in pra=
ctice always run my own full node instances to connect to due to the three =
fatal flaws: 1) no mechanism for short proofs of tx nonexclusion, txout uns=
pentness, block validity, nor the ability to find the first instance of the=
use of a scriptPubKey without full blockchain scanning, 2) poor privacy, 3=
) lack of incentives to run servers.</p>
<p dir=3D"ltr">I always felt that BIP37 was necessarily a step towards a cl=
ient/server architecture.</p>
<p dir=3D"ltr">Having said that, I have found the filter mechanism useful, =
if only because no "special" server is required. However, in prac=
tice I'd rather make the distinction between trustless peers and a clie=
nt/server model more explicit.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 24, 2015, 10:41=
AM=C2=A0Wladimir J. van der Laan via bitcoin-dev <<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 24, 2015 =
at 05:37:51PM +0000, Matt Corallo wrote:<br>
> Its more of a statement of "in the future, we expect things to ha=
ppen<br>
> which would make this an interesting thing to do, so we state here tha=
t<br>
> it is not against spec to do so". Could reword it as "NODE_B=
LOOM is<br>
> distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM bu=
t<br>
> not NODE_NETWORK (though there is little reason to do so now, some<br>
> proposals may make this more useful in the future)"?<br>
<br>
Yes, it makes sense to not explicitly exclude it.<br>
Looks good to me.<br>
<br>
Wladimir<br>
<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>
--001a113ec3a688e183051e125fbd--
|
