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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev