From mboxrd@z Thu Jan 1 00:00:00 1970 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 <<a href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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> > On Mon, Aug 24, 2015 at 05:37:51PM +0000, Matt Corallo via bitcoin-dev= wrote:<br> >> Its more of a statement of "in the future, we expect things t= o happen<br> >> which would make this an interesting thing to do, so we state here= that<br> >> it is not against spec to do so". Could reword it as "NO= DE_BLOOM is<br> >> distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOO= M but<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> > ACK<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> --089e01536c1062914e051e129b5e--