From: Pieter Wuille <pieter.wuille@gmail•com>
To: Tamas Blummer <tamas.blummer@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Gregory Maxwell <gmaxwell@gmail•com>, Jim Posen <jimpo@coinbase•com>
Subject: Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal
Date: Thu, 7 Feb 2019 12:36:25 -0800 [thread overview]
Message-ID: <CAPg+sBjA5HUttt9AGHcR-dQmV-rGeb3bHXQ12OGVupL3M++TdA@mail.gmail.com> (raw)
In-Reply-To: <CAGc5dgZOGZh61TZL1YghqnGez59psyhfSz1tv3KcbS6dgp8cww@mail.gmail.com>
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
next prev parent reply other threads:[~2019-02-07 20:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 11:41 Tamas Blummer
2019-02-04 20:18 ` Jim Posen
2019-02-04 20:59 ` Tamas Blummer
2019-02-05 1:42 ` Olaoluwa Osuntokun
2019-02-05 12:21 ` Matt Corallo
2019-02-06 0:05 ` Olaoluwa Osuntokun
2019-02-05 20:10 ` Tamas Blummer
2019-02-06 0:17 ` Olaoluwa Osuntokun
2019-02-06 8:09 ` Tamas Blummer
2019-02-06 18:17 ` Gregory Maxwell
2019-02-06 19:48 ` Tamas Blummer
[not found] ` <CAAS2fgQX_02_Uwu0hCu91N_11N4C4Scm2FbAXQ-0YibroeqMYg@mail.gmail.com>
2019-02-06 21:17 ` Tamas Blummer
2019-02-07 20:36 ` Pieter Wuille [this message]
2021-10-03 9:53 ` Dustin Dettmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBjA5HUttt9AGHcR-dQmV-rGeb3bHXQ12OGVupL3M++TdA@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=jimpo@coinbase$(echo .)com \
--cc=tamas.blummer@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox