From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 96CE9BC2 for ; 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 ; Mon, 24 Aug 2015 17:59:05 +0000 (UTC) Received: by iodb91 with SMTP id b91so157474996iod.1 for ; 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 Date: Mon, 24 Aug 2015 17:58:55 +0000 Message-ID: To: "Wladimir J. van der Laan" , Matt Corallo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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.

I always felt that BIP37 was necessarily a step towards a cl= ient/server architecture.

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.


On Mon, Aug 24, 2015, 10:41= AM=C2=A0Wladimir 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 ha= ppen
> which would make this an interesting thing to do, so we state here tha= t
> it is not against spec to do so". Could reword it as "NODE_B= LOOM is
> distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM bu= t
> 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/mail= man/listinfo/bitcoin-dev
--001a113ec3a688e183051e125fbd--