Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E7F33CB7 for ; Tue, 23 Jul 2019 14:47:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (195-159-176-226.customer.powertech.no [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 434CD224 for ; Tue, 23 Jul 2019 14:47:33 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hpw4f-000Yf8-Mv for bitcoin-dev@lists.linuxfoundation.org; Tue, 23 Jul 2019 16:47:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Tue, 23 Jul 2019 16:47:18 +0200 Message-ID: References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Openpgp: preference=signencrypt Autocrypt: addr=andreas@schildbach.de; keydata= xsDiBD/S9DARBACgg0IF3cCFaNXbQtCAZBpiZRawQAfsfL87sHhy1xq3UwR4RmQKsWjtZQ9C 7kSDTkzzn7Sqg+YtXgiJdGeYinSMy+6mBKQjtrIKLikbjB1ORTfA29m7m7VTBY9X3Cvmpm0+ 0mWvrQ9hSpq8adXitY4Z+/VB/1YSo77RakfNr3sQOwCgzrXH37AlAu307IgOOFnI1y78Y4cD /29gtaY3/u8ThFI/mXBOHnfXaIVGLYKtlf2Lyj2JnixhhzxEpuDJ0lkcyNQ0N7Ky8ohJS3tG ShwHjsQNtqK2V1DomsUnDI/W4hJNCSd0zfIoQgHvE1RbOyOpz4F+CNw8uQcxwE5FmwRtk6xa zJsiMVKLFhKr6LnMoVaNi8mZZFKzA/9HcXAse5epfrZD1tt7dHr58+egIA0OkoQ8oUgqCgN1 4qmUxQoWTdmvet0E+XaHcowr1fXu79uQ2zuvHSk/S4mjP6uT+XOxENVcKRUtyEBtSzFDyyCj 853KrBQSppCgxS8loHj1g1YIKqu97kGVtfmHM9L9TPVA1opuYOcJh7iJ9s0qQW5kcmVhcyBT Y2hpbGRiYWNoIDxhbmRyZWFzQHNjaGlsZGJhY2guZGU+wl4EExECAB4FAj/S9DACGwMGCwkI BwMCAxUCAwMWAgECHgECF4AACgkQymYr4YuHemD4NACePnpSANmR2vrZVv+BteOva6gzOJ0A nioa6JoKCYx3jQOIqoBGcBUkc8q1zsFNBD/S9DgQCACctel4AnL7nuh+Uv+IBz0GMvu6Ewdn sVCOLf54neIxuaW4BC5RYAdS6Tkp3hxv+ZfA0Uv6X3nz4tOsVHD50+CCq51pRlnbUwcWcn9e nynJyddTjei+JmJrdOJOAzWa/al8YagjQSZqgD6mmPUy/a201Bh0L2zbLmxQMFg+PPB81j4y UmSXmhYzg/+SonZ3lr9pJNtoZszg95NDyYBceiF5RSw4Qusi+C5/W3nIKzuaIKZijE9Dvo6D W6ggbB/gSxDTSjvrnvvXeG1SdlKLeFvsJ9y/0ro3EP01RRVJvA5RaM5W2MRbwGuSRcSw8B74 6ijEOqSh0IYLXoHdV7Vj4Qt/AAMFB/9ZcgxVGvs2ob6MCTVdPLlVKRKDn7RjZiDE6hRa/jp7 ewdstjjc22DU/jCz16IX75B/sr1cDJqbChONFdljjQNWe2cTFXSazUjsyZa35+KvehDi7cAU +vCYmisMpkPM41hR6HYqjadDp6gOVJTnHPcJ6EPdgUQTsNQH3dCTD68b5WwzBEBNLdwyDGLK McExzaOClwwSeHBmnj72O7Chdhn/M/2+fpTUPqhp/0sflVyR/ILyc/KEp85pwani2dXuZ02i gSaSIBwQJOVrjsUTwp2Wxdmywt13/cGGVlsGLe8lY0Kv6G43/eip+42OfIVhxRgARRtJ5KjK chTLwfl3tbgawkkEGBECAAkFAj/S9DgCGwwACgkQymYr4YuHemAWjACgtRlmiISVlCf7/mum klJfLM6wKIMAnA2uS1BS4d7GJkQp09ViaWmUUsMc In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 24 Jul 2019 11:36:19 +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: Tue, 23 Jul 2019 14:47:34 -0000 (Rather than replying individually, I try to address questions and add my remarks in one post.) > Finally, regarding alternatives, the filter-generation code for > BIP 157/158 has been in Bitcoin Core for some time, though the > P2P serving side of things appears to have lost any champions > working on it. BIP 157/158 is not an alternative to BIP 37: 1) It causes way too much traffic for mobile users, and likely even too much traffic for fixed lines in not so developed parts of the world. 2) It filters blocks only. It doesn't address unconfirmed transactions. 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. 4) The filters are not yet committed to the blockchain. Until that happens we'd have to trust a server to provide correct filters. > Can you specify exactly which wallets those are? Bitcoin Wallet, Breadwallet, BISQ and many smaller ones. > the DNS seed infrastructure among others can easily direct > wallets to those nodes Last I checked none of the seeds did. But I agree this would be nice to have. > We eventually can’t expect - in the long run - that nodes provide > disk/CPU intense services for free to clients not contributing back > to the network. I'm disappointed to learn that supporting 10M wallets gets discredited down to "no contribution". Each node of course supports just a number of them, but still... > The fact that nobody cared about extending it for SW may also > underline that BIP37 is seen as a conceptual mistake and/or "low > interest in further extensions“. I suspect this is a fallacy. BIP37 doesn't need to be extended for SegWit. See Bitcoin Wallet and Breadwallet, both support SegWit and use the original BIP 37. It's true however that BIP 37 could be made simpler to work with, more future-proof and more private by simply matching output scripts. > [1] https://github.com/petertodd/bloom-io-attack This claims to be a proof of concept, but it's missing the concept. I could not find a description of the attack and why is it likely to be exploited (and why it hasn't been exploited yet). > CPU DoS attacks are also possible If such an attack exists, it should be easy to defend against. Filter is using too much CPU time → disconnect and blacklist the IP for some time. I vaguely remember the infrastructure for misbehaving peers is already present in bitcoind. As a side note, Coinbase just announced their 30M'th wallet. I'm convinced this massive run into custodial wallets is caused by the public realizing around Dec 2017 that Bitcoin fails to scale. IMHO, BIP 37 is the only scaling technology that has proven successful and could – if supported and improved rather than choked – continue to help holding against the bitbanks trend.