Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 95C08CB6 for ; Sat, 14 Apr 2018 19:46:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16A89675 for ; Sat, 14 Apr 2018 19:46:03 +0000 (UTC) Received: by mail-it0-f48.google.com with SMTP id 71-v6so7080978ith.2 for ; Sat, 14 Apr 2018 12:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oEaqAVBNYAO4P54TO4UOiEJxObpSeiphvdSZp8u1gWs=; b=t6MOdaFVcpBuHVXmRq5DN2h9F2B2eJhXZzYyjcyOWFHZF7oBs3SKxSsFF3W5AwY0jp 7D30AXoRYUSGR2+sl+JxpFA6BKojBZdRmkn7JzQotOgW7+9OWdPY16LLGcqqWKZgWN3l B0GZR7vPFfvFmrNwAPEoh+em325qXPu3NHpCqK3E0MKdHeCFPc2Ed8XkStEy2daUSjlP ygOSvuyluDIGFt85KkauG1U+Y1bccp/R2ikKvaeV8fHOGWLxZaqe/dbRx7fydtADTZUe Cz965yE35IgHtN+0rTOv8jYOZLSnKvo3QRH1alI4MEVeJJshGgFlP8zV+jBWor4SdeyY NOdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oEaqAVBNYAO4P54TO4UOiEJxObpSeiphvdSZp8u1gWs=; b=TxNZlfTMMbCHbwztWxLQHl/yMtEGAcVfCzTqGqJUhSEqDaUKm1fyEuI/7m6a1CG5vC G36h5qoM12HU3XIX6Yul6oP2zgeHQJwifeHWQbOp2uyPO8eWtNvZSviU8bqzjp5Fm8Hv YU5CMMAh04LFkqygn1AIlo8uG4esJ2BfZeqxgx1PN+L5s92BKvikmyfZt1wnz9WrWwJr rsjB1cgbxtREtViIPTchkW3i2+CqG00AUOHiu+ipU9evZU2026iuvoUNSx6WJ7/TyoCc g6SBVRUplbn+5lImY1yCN4REv9sGXBOp2m1Cig9kDEGI56/4ejeN9YKYS1DYQMxtNmi8 z3Rw== X-Gm-Message-State: ALQs6tD7ANIZf2xdXrpkK+eZbzhWhmOLHfqBUsC6GMzatdxKJwSx4key 3fFkOQf3RcPqOGdZGL5l5ikyDDmxS2A9PcdYdmY= X-Google-Smtp-Source: AIpwx4+2p3RjTvKR88xs4LGgyuZnufZfqC8FtDuB0OQJXnkSZAEtT7Oktoz+hAw2rN0ag8J8lo5v0FqYLydrKqCyxNM= X-Received: by 2002:a24:5b06:: with SMTP id g6-v6mr10012683itb.43.1523735162221; Sat, 14 Apr 2018 12:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.52.80 with HTTP; Sat, 14 Apr 2018 12:46:01 -0700 (PDT) In-Reply-To: References: <4A0CD31A-8745-4425-99FC-5DF12FA3B917@jonasschnelli.ch> From: Jim Posen Date: Sat, 14 Apr 2018 12:46:01 -0700 Message-ID: To: Christian Decker Content-Type: multipart/alternative; boundary="000000000000137e5b0569d43da6" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Sat, 14 Apr 2018 19:50:42 +0000 Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BloomFilter issue with segwit addresses 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, 14 Apr 2018 19:46:03 -0000 --000000000000137e5b0569d43da6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To Christian's point about privacy, I'll take this opportunity to shamelessly review beg on https://github.com/bitcoin/bitcoin/pull/12254, the PR for BIP 158 implementation (but not 157). On Sat, Apr 14, 2018 at 9:14 AM, Christian Decker < decker.christian@gmail.com> wrote: > Note that this would compound the privacy leak that Jonas Nick used to > identify address clusters via the bloom filters in one of his publication= s. > By reducing the false positives when matching you can get very detailed > clusters. Then again we know that bloom filters aren't good for privacy > anyway, so this might be a non-issue. > > On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev linuxfoundation.org> wrote: > >> Why not add the outpoints owned by the wallet to the filter and watch fo= r >> those instead of elements in the input script or witness data? >> >> On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> Hi Andreas >>> >>> Thanks for bringing this up and this seems indeed to be suboptimal. >>> >>> > I wonder if Bitcoin Core would be willing to extend the BIP37 matchin= g >>> > rules such that data elements in the witness are also matched against= ? >>> >>> Bitcoin Core is not an identity that can be =E2=80=9Ewilling to extend= =E2=80=9C (or >>> reject) a feature. >>> Someone needs to come up with a proposal (pull request). >>> >>> Maybe an extension for BIP37 would make sense (*meh*). >>> Just inserting the witness data into the bloom filter seems to be an >>> easy solution (CBloomFilter::IsRelevantAndUpdate()) >>> >>> /jonas >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000137e5b0569d43da6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To Christian's point about privacy, I'll take this= opportunity to shamelessly review beg on=C2=A0https://github.com/bitcoin/bitcoin/pull/12254= , the PR for BIP 158 implementation (but not 157).

On Sat, Apr 14, 2018 at 9:14 AM,= Christian Decker <decker.christian@gmail.com> wrot= e:
Note that this would= compound the privacy leak that Jonas Nick used to identify address cluster= s via the bloom filters in one of his publications. By reducing the false p= ositives when matching you can get very detailed clusters. Then again we kn= ow that bloom filters aren't good for privacy anyway, so this might be = a non-issue.

On Sat, Apr 14, 2018, 00:17 Jim Posen via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Why not add the outpo= ints owned by the wallet to the filter and watch for those instead of eleme= nts in the input script or witness data?
On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnel= li via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
Hi Andreas

Thanks for bringing this up and this seems indeed to be suboptimal.

> I wonder if Bitcoin Core would be willing to extend the BIP37 matching=
> rules such that data elements in the witness are also matched against?=

Bitcoin Core is not an identity that can be =E2=80=9Ewilling to exte= nd=E2=80=9C (or reject) a feature.
Someone needs to come up with a proposal (pull request).

Maybe an extension for BIP37 would make sense (*meh*).
Just inserting the witness data into the bloom filter seems to be an easy s= olution (CBloomFilter::IsRelevantAndUpdate())

/jonas

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev

--000000000000137e5b0569d43da6--