Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 207B3D7E for ; Sun, 15 Apr 2018 18:37:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BBF7473 for ; Sun, 15 Apr 2018 18:37:55 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1f7mV3-0005rz-Rm for bitcoin-dev@lists.linuxfoundation.org; Sun, 15 Apr 2018 20:35:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Sun, 15 Apr 2018 20:37:45 +0200 Message-ID: References: <4A0CD31A-8745-4425-99FC-5DF12FA3B917@jonasschnelli.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, FORGED_MUA_MOZILLA,RDNS_NONE autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Sun, 15 Apr 2018 18:37:56 -0000 Yes, I guess the quicker filter exhaustion must be the reason why bitcoinj doesn't make use of outpoints in filters for standard transactions. I'll look into if I can change that. On 04/14/2018 06:14 PM, Christian Decker via bitcoin-dev 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 > publications. 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 > > wrote: > > Why not add the outpoints owned by the wallet to the filter and > watch for 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 > > 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 „willing to extend“ > (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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >