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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
Precedence: list

--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 &quot;special&quot; server is required. However, in prac=
tice I&#39;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 &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; 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>
&gt; Its more of a statement of &quot;in the future, we expect things to ha=
ppen<br>
&gt; which would make this an interesting thing to do, so we state here tha=
t<br>
&gt; it is not against spec to do so&quot;. Could reword it as &quot;NODE_B=
LOOM is<br>
&gt; distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM bu=
t<br>
&gt; not NODE_NETWORK (though there is little reason to do so now, some<br>
&gt; proposals may make this more useful in the future)&quot;?<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--