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 5BAB6E50 for ; Mon, 22 Jul 2019 17:27:36 +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 02507224 for ; Mon, 22 Jul 2019 17:27:27 +0000 (UTC) Received: from ishibashi.lan (adsl-98-70-226-244.gnv.bellsouth.net [98.70.226.244]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id D7E9D38A0DAE; Mon, 22 Jul 2019 17:26:59 +0000 (UTC) X-Hashcash: 1:25:190722:bitcoin-dev@lists.linuxfoundation.org::gFFaCmQtfBecaBbc:bCqZK X-Hashcash: 1:25:190722:andreas@schildbach.de::Z7fDvF8zz6crA7Og:8/j4 From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Andreas Schildbach Date: Mon, 22 Jul 2019 17:26:56 +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="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201907221726.58027.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: Mon, 22 Jul 2019 20:38:39 +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: Mon, 22 Jul 2019 17:27:36 -0000 On Sunday 21 July 2019 22:56:33 Andreas Schildbach via bitcoin-dev wrote: > An estimated 10+ million wallets depend on that NODE_BLOOM to be > updated. Where do you see this number? I think it would be useful to chart. > So far, I haven't heard of an alternative, except reading all > transactions and full blocks. Electrum has a JSON-based protocol that can provide information much more efficiently. Currently, this does require nodes that run additional software and/or indexes, but there are plenty of them available, and there are steps that can be taken to improve that situation. > > It is not anticipated that > > this will result in a significant lack of availability of > > NODE_BLOOM-enabled nodes in the coming years > > Why don't you anticipate that? People almost never change defaults, > especially if it's not for their own immediate benefit. At the same > time, release notes in general recommend updating to the latest version. > I *do* anticipate this will reduce the number of nodes usable by a large > enough amount so that the feature will become unstable. Many users run older versions, and do not update immediately. Today, only 42% of listening nodes are using 0.18. (If it helps ease the concern, we can keep bloom enabled by default in Knots longer.) > I strongly recommend postponing this change until an alternative exists > and then give developers enough time to implement, test and roll out. There will be time to do so, since the functionality won't disappear overnight. Luke