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 633B5BDDB for ; Thu, 7 Feb 2019 20:36:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA50713A for ; Thu, 7 Feb 2019 20:36:38 +0000 (UTC) Received: by mail-ot1-f49.google.com with SMTP id n8so2176722otl.6 for ; Thu, 07 Feb 2019 12:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AXDv6TNQN4Etn0h3YCeSoBftb9aL3IjbhOT1mnQKFIU=; b=G4Ya2WssDri1LhmuNT2uud2d7FJ1Xq3CDpZkzuVL65S/sChFxe2wzArOb1NiXTfmaY UvCOzkQdAfXfkYebbRUGCbHb+ihkEf4OgBDpTOK+/zDIyrBG2Hews8oHWzY2PPjfAA16 CZ1MdKTJqmU4unQQDwS1/k0fTuE2/8GJOWuuRh+iqKnBOsLaV5cM0Te040KHruWTqOo/ E9EQL4X6hzr9648gU1RzU0/tDRzMFUypFAdq49jEB+LOooEeOQFee4EbbNoC4GV4ko5Z PDUx8/ukU0Ul6hjuptZtQjcnd/5rg/TiVfPmB7qFiHsStDnvWBl18vjlT1vYwAnTMvRp Mk2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AXDv6TNQN4Etn0h3YCeSoBftb9aL3IjbhOT1mnQKFIU=; b=dDwCZW0526q1xVhvVUWPm2D1tpOVUTSpfT0/xr6ZekeulJdIoMbwCb/uusiB9LAdTX fE7WK3kqWWLCcaQVITDczn3DSSoKcgZ4i5N9HdffFikNOK8DzVVU0Q7fKI6VN82B+BNG 0DjIp4TA511Nu5MK8KEUtrOfawnDpTtDX+cZMfWpYk+h2W9iTcoOH3ybv06eBPbC4Tog Xenw4oiuOJb7nlslFYix1n9Ho2DmjFwpLkYFs8Obk5aNfzW1huFu08F7D8P8QGvlo9B2 PWVyHEVcc77AuIzpOKOhBHAaNLd/nUZm80mtBoWf+u+CCRTLKn+N8j/YdDGxs5sLINEM mYug== X-Gm-Message-State: AHQUAuaoKQWnxhubEjYDARSIbhiM/NZHUihGL0HQOpMS/IfPtq9w5xbs syWWGszwnpSdyMNHkzEjTxmm04PZVm2ZBWmy5KU= X-Google-Smtp-Source: AHgI3IbmEPau1xc25gdWy9td1Cx5NkCmmZIZcknW501hlwBGuVDWy6fojJXthU4ZYiSDoEmGgjbMYEiqfxbOOQSZzGE= X-Received: by 2002:a05:6808:c1:: with SMTP id t1mr78961oic.131.1549571797881; Thu, 07 Feb 2019 12:36:37 -0800 (PST) MIME-Version: 1.0 References: <6D57649F-0236-4FBA-8376-4815F5F39E8A@gmail.com> <6D36035C-A675-4845-9292-3BC16CD19B41@gmail.com> <5A850549-B6C9-4590-BA9B-0D69BBE531F9@gmail.com> In-Reply-To: From: Pieter Wuille Date: Thu, 7 Feb 2019 12:36:25 -0800 Message-ID: To: Tamas Blummer , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 08 Feb 2019 14:31:49 +0000 Cc: Gregory Maxwell , Jim Posen Subject: Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:36:39 -0000 On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev 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