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 0F0721334 for ; Sat, 2 Jun 2018 00:01:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 592F4108 for ; Sat, 2 Jun 2018 00:01:56 +0000 (UTC) Received: by mail-wm0-f68.google.com with SMTP id q4-v6so8113731wmq.1 for ; Fri, 01 Jun 2018 17:01:56 -0700 (PDT) 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=GpgjU9ZF4uHnwdyU9Yib6iW/X8ZEsi6Hm62egx7BBuU=; b=qEfm7W1+IZZy0BZcDsf84xm/iPHSJx9+OvgT0qePzGZ16zJQem6l+tHVR9yIt+AxZa DdDNySIAa3L+7mN/Wp8jGf/WVNsTMGPKUAC8LLVztvGjhxFInLAPMC3gLmtrQs5cAoaf elcjG+o0Oy+8FYIfSSqh4juypp7KRaIyToZ7fVeFV1oWGQ8W3b5/8r1iYZVjjNX0Z6zi 7K+mIXTkacM+0GR8Z/4mQLr4/Uj6NU6F1gkAaEPqtuiSkqcn02dH5F4VNCGfcNl5hD+g IUAUw8HSJR7qS+EO5ksfhEzJGJUMdQRvJveOyFdDgZh+24Bo5hXcC8MCtPMI1omUjPSN 7rrw== 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=GpgjU9ZF4uHnwdyU9Yib6iW/X8ZEsi6Hm62egx7BBuU=; b=aWRBQ9hfRl3inZIHrJkclZQjU28+ySSaqea+M41lSEdcIMzr4kPrYnG2RhVSkZI+Lk xLETzP8X4/YtLLsHMi/ARbfjl8Rt1JcLwksvEX7J9F3FVkBQrPgCbcTTcNDLoMAlxk9i /u6Wo+OK4PpTsIo4f3ZfTyyQt7TFK5eAxztJpMm7xL2uNFuzTOGsVIqyfsScCjWRdRAm OSvcS7eXF2hXO1jIaZtRywPSlkUy21ozUQze7YrRDRu8rqXW4JwtyZG1+a0Ntyhu4E54 whZiTEmUbxJ+eV6QJMbbaUZcCS55VSf54+NfJ5a/tlOVQEd4hztTP2Eacz0mlx8sv8yG cXzA== X-Gm-Message-State: ALKqPwdspe+VGm1MBldVVSWTiI3wdHUF+QFIRQhP3WPD0aO/MtpHFVHz atcRVbZTFlYX5lCBDFKeluByP00txcW0rSQaCW4= X-Google-Smtp-Source: ADUXVKIXfL0OfkqdSqSRaxKJtLRcg6vJbwOBRUfaPh78xi7vZhvLYmxgu/7umP+7ki4EsOC/7rXJgYzRk+VgH6+TSt8= X-Received: by 2002:a50:a3b8:: with SMTP id s53-v6mr14544324edb.271.1527897714817; Fri, 01 Jun 2018 17:01:54 -0700 (PDT) MIME-Version: 1.0 References: <22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com> <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com> In-Reply-To: From: Olaoluwa Osuntokun Date: Fri, 1 Jun 2018 17:01:43 -0700 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary="0000000000008b8043056d9d68cc" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size 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: Sat, 02 Jun 2018 00:01:57 -0000 --0000000000008b8043056d9d68cc Content-Type: text/plain; charset="UTF-8" > A typical network attacker (e.g. someone on your lan or wifi segmet, or > someone who has compromised or operates an upstream router) can be all of > your peers. This is true, but it cannot make us accept any invalid filters unless the attacker is also creating invalid blocks w/ valid PoW. > The original propsal for using these kinds of maps was that their digests > could eventually be commited and then checked against the commitment, > matching the same general security model used otherwise in SPV. Indeed, but no such proposal for committing the filters has emerged yet. Slinging filters with new p2p messages requires much less coordination that adding a new committed structure to Bitcoin. One could imagine that if consensus exists to add new committed structures, then there may also be initiatives to start to commit sig-ops, block weight, utxo's etc. As a result one could imagine a much longer deployment cycle compared to a pure p2p roll out in the near term, and many applications are looking for a viable alternative to BIP 37. > Unfortunately, using the scripts instead of the outpoints takes us further > away from a design that is optimized for committing (or, for that matter, > use purely locally by a wallet)... I agree that using the prev input scripts would indeed be optimal from a size perspective when the filters are to be committed. The current proposal makes way for future filter types and it's likely the case that only the most optimal filters should be committed (while other more niche filters perhaps, remain only on the p2p level). -- Laolu On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell wrote: > On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev > wrote: > > One notable thing that I left off is the proposed change to use the > previous > > output script rather than the outpoint. Modifying the filters in this > > fashion would be a downgrade in the security model for light clients, as > it > > Only if you make a very strong assumption about the integrity of the > nodes the client is talkign to. A typical network attacker (e.g. > someone on your lan or wifi segmet, or someone who has compromised or > operates an upstream router) can be all of your peers. > > The original propsal for using these kinds of maps was that their > digests could eventually be commited and then checked against the > commitment, matching the same general security model used otherwise in > SPV. > > Unfortunately, using the scripts instead of the outpoints takes us > further away from a design that is optimized for committing (or, for > that matter, use purely locally by a wallet)... > --0000000000008b8043056d9d68cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> A typical network attacker (e.g.=C2=A0 someone o= n your lan or wifi segmet, or
> someone who has compromised or= operates an upstream router) can be all of
> your peers.

This is true, but it cannot make us accept any invalid= filters unless the
attacker is also creating invalid blocks w/ v= alid PoW.

> The original propsal for using thes= e kinds of maps was that their digests
> could eventually be c= ommited and then checked against the commitment,
> matching th= e same general security model used otherwise in SPV.

Indeed, but no such proposal for committing the filters has emerged yet.=
Slinging filters with new p2p messages requires much less coordi= nation that
adding a new committed structure to Bitcoin. One coul= d imagine that if
consensus exists to add new committed structure= s, then there may also be
initiatives to start to commit sig-ops,= block weight, utxo's etc. As a
result one could imagine a mu= ch longer deployment cycle compared to a pure
p2p roll out in the= near term, and many applications are looking for a
viable altern= ative to BIP 37.

> Unfortunately, using the scr= ipts instead of the outpoints takes us further
> away from a d= esign that is optimized for committing (or, for that matter,
>= use purely locally by a wallet)...

I agree that u= sing the prev input scripts would indeed be optimal from a
size p= erspective when the filters are to be committed. The current proposal
=
makes way for future filter types and it's likely the case that on= ly the
most optimal filters should be committed (while other more= niche filters
perhaps, remain only on the p2p level).
=
-- Laolu


=
On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell <gmaxwell@gmail.com> wrote:
=
On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osu= ntokun via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> One notable thing that I left off is the proposed change to use the pr= evious
> output script rather than the outpoint. Modifying the filters in this<= br> > fashion would be a downgrade in the security model for light clients, = as it

Only if you make a very strong assumption about the integrity of the
nodes the client is talkign to. A typical network attacker (e.g.
someone on your lan or wifi segmet, or someone who has compromised or
operates an upstream router) can be all of your peers.

The original propsal for using these kinds of maps was that their
digests could eventually be commited and then checked against the
commitment, matching the same general security model used otherwise in
SPV.

Unfortunately, using the scripts instead of the outpoints takes us
further away from a design that is optimized for committing (or, for
that matter, use purely locally by a wallet)...
--0000000000008b8043056d9d68cc--