MIME-Version: 1.0
References: <6D57649F-0236-4FBA-8376-4815F5F39E8A@gmail.com>
	<CADZtCSgKu1LvjePNPT=0C0UYQvb47Ca0YN+B_AfgVNTpcOno4w@mail.gmail.com>
	<CDAFC2F7-A0AD-460B-B5B1-A717F7EC700E@gmail.com>
	<CAO3Pvs_gvYy99Bch=7RwVszM_0PFTKUyqDVok=xfm4OOcqwaaQ@mail.gmail.com>
	<6D36035C-A675-4845-9292-3BC16CD19B41@gmail.com>
	<CAO3Pvs_Ai9d_uHC2a3ndGXhBoV-PDp2y_NShkbn=hRuzu=wNFw@mail.gmail.com>
	<5A850549-B6C9-4590-BA9B-0D69BBE531F9@gmail.com>
	<CAAS2fgRY-EaPMORjipJuysi-z61VUMivOKmSeO1Rv7vXOPeLKQ@mail.gmail.com>
	<CAGc5dgbm0wQKs4bAyN8bPdqq=RbS--TvcvUOmX2_rMTCx0POAg@mail.gmail.com>
	<CAAS2fgQX_02_Uwu0hCu91N_11N4C4Scm2FbAXQ-0YibroeqMYg@mail.gmail.com>
	<CAGc5dgZOGZh61TZL1YghqnGez59psyhfSz1tv3KcbS6dgp8cww@mail.gmail.com>
In-Reply-To: <CAGc5dgZOGZh61TZL1YghqnGez59psyhfSz1tv3KcbS6dgp8cww@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 7 Feb 2019 12:36:25 -0800
Message-ID: <CAPg+sBjA5HUttt9AGHcR-dQmV-rGeb3bHXQ12OGVupL3M++TdA@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Jim Posen <jimpo@coinbase.com>
Subject: Re: [bitcoin-dev] Interrogating a BIP157 server,
	BIP158 change proposal
Precedence: list

On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I did restart the discussion which I read and participated in at its first instance because implementing the current proposal taught me how problematic as is until not committed and because I have not seen a sign to assume commitment was imminent.

Hi Tamas,

I think you're confusing the lack of sign of imminent commitment for a
sign it isn't the end goal. Changes in consensus rules take a while,
and I think adoption of BIP157 in a limited setting where offered by
trusted nodes is necessary before we will see a big push for that.

In my personal view (and I respect other opinions in this regard),
BIP157 as a public network-facing service offered by untrusted full
nodes is fair uninteresting. If the goal wasn't to have it eventually
as a commitment, I don't think I would be interested in helping
improving it. There are certainly heuristics that reduce the risk of
using it without, but they come at the cost of software complexity,
extra bandwidth, and a number of assumptions on the types of scripts
involved in the transactions. I appreciate work in exploring more
possibilities, but for a BIP157-that-eventually-becomes-a-commitment,
I think they're a distraction. Unless you feel that changes actually
benefit that end goal, I think the current BIP157 filter definition
should be kept.

There is no problem however in optionally supporting other filters,
which make different trade-offs, which are intended to be offered by
(semi) trusted nodes. Still, for the reasons above I would very much
like to keep those discussions separate from the
to-be-committed-filter.

Cheers,

-- 
Pieter