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 04384A95 for ; Sat, 27 Jul 2019 19:20:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8ECAAFE for ; Sat, 27 Jul 2019 19:20:00 +0000 (UTC) Received: from ishibashi.lan (adsl-67-34-245-3.asm.bellsouth.net [67.34.245.3]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id EEAC338A0D8F; Sat, 27 Jul 2019 19:19:51 +0000 (UTC) X-Hashcash: 1:25:190727:bitcoin-dev@lists.linuxfoundation.org::FAbu+jQtD8/hanji:67s4 X-Hashcash: 1:25:190727:andreas@schildbach.de::uoEKTpS=TwQeCD7A:k6xw From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Andreas Schildbach Date: Sat, 27 Jul 2019 19:19:49 +0000 User-Agent: KMail/1.9.10 References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201907271919.49999.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED 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, 27 Jul 2019 20:17:43 +0000 Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default 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, 27 Jul 2019 19:20:01 -0000 On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote: > 3) Afaik, it enforces/encourages address re-use. This stems from the > fact that the server decides on the filter and in particular on the > false positive rate. On wallets with many addresses, a hardcoded filter > will be too blurry and thus each block will be matched. So wallets that > follow the "one address per incoming payment" pattern (e.g. HD wallets) > at some point will be forced to wrap their key chains back to the > beginning. If I'm wrong on this one please let me know. BTW, you are indeed wrong on this. You don't need to match every single address the wallet has ever used, only outstanding addresses that haven't been paid. ;) Luke