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 270D9CA9 for ; Thu, 17 May 2018 07:47:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch [138.201.55.219]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0F3606CF for ; Thu, 17 May 2018 07:47:46 +0000 (UTC) Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002) id D915515E4C9F; Thu, 17 May 2018 09:47:45 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from [192.168.0.8] (cable-static-238-67.teleport.ch [213.188.238.67]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 44C9A15E1B3C; Thu, 17 May 2018 09:47:44 +0200 (CEST) From: Jonas Schnelli Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Priority: 3 Date: Thu, 17 May 2018 09:47:34 +0200 References: To: Caius Cosades , Bitcoin Protocol Discussion In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) X-Virus-Scanned: clamav-milter 0.99.4 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean Subject: Re: [bitcoin-dev] Moving away from BIP37, unsetting NODE_BLOOM 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: Thu, 17 May 2018 07:47:48 -0000 --Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Caius Thanks for brining this up. As far as it looks, one of the major SPV library does not yet respect = the NODE_BLOOM service flag [1]. Unsure sure about others. It think disabling NODE_BLOOM services by default in full node = implementations makes sense as soon as BIP158 [2] (compact block = filters) has been implemented and therefore NODE_COMPACT_FILTERS is = signalled broadly. Unsure if it would make sense to even wait for block = filter commitment softfork (probably no). Then, the question is, if there are alternatives for mempool filtering = (display unconfirmed transactions) or if the protocol recommendation are = to disable that by default or recommend to use centralised filtering = technique via wallet provider infrastructure (privacy?!). I guess everyone here agrees that there are major privacy and = load-distribution issues with BIP37, and, that it should be disabled in = the long run. But, due to the lack of alternatives, there is the risk of breaking = existing SPV client models and thus pushing users to complete = centralised validation-solutions (and even towards centralised = key-storage), which, may result in making privacy and security even more = worse. I personally miss a long term concept how to keep non expert users (or = say light clients) close to the p2p protocol in a decentralized fashion. = Unclear how decentralized fee estimations and =E2=80=9Eincoming = transactions=E2=80=9C (which is something users want even if it's a = broken concept) are handled in the future. =E2=80=94 /jonas [1] https://github.com/bitcoinj/bitcoinj/pull/1212 [2] https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki > Am 16.05.2018 um 23:22 schrieb Caius Cosades via bitcoin-dev = : >=20 > As previously discussed[0][1][2] on the mailing list, github issue = commentary, and IRC channels, there's substantial reason to disable = BIP37 in network nodes which are getting stronger as the size of the = chain increases. BIP37 has significant denial of service issues which = are unsolvable in the design, it introduces undue load on the bitcoin = network by default, and doesn't provide an acceptable amount of = security and reliability to "lightweight wallets" as originally = intended. >=20 > BIP37 allows "lightweight wallets" to connect to nodes in the network, = and request that they load, deseralize, and expensively apply an = arbitrary bloom filter to their block files and mempool. This should = never have been the role of nodes in the network, rather it should have = been opt-in, or performed by a different piece of software entirely. The = inability of the nodes to cache the responses or meaningfully rate limit = them makes it detrimental to serve these requests. >=20 > BIP37 was intended to have stronger privacy than it does in = reality[3][4], where effectively any node that can capture `filterload` = and `filteradd` responses can trivially de-anonymize an entire wallet = that has connected irrespective of the amount of noise they add to their = filters. The connected node lying by omission is undetectable by any = wallet software, where they will be lead to believe that there are no = matching responses; this is counter-able by further destroying privacy = and loading down the network by having multiple peers simultaneously = return filter results and hoping that at least one isn't lying. >=20 > NODE_BLOOM has been implemented already which allows nodes to signal = in their service message that they do, or do not support filtering. I = suggest that in the next major release this is defaulted to 0, and any = software relying on BIP37 move to using other filtering options, or = another piece of dedicated software to serve the requests. Future = releases of the reference software should remove BIP37 commands = entirely. >=20 >=20 > [0]: = https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_dev= s_not_xt_makes_bitcoin/cu9xntf/?context=3D3 > [1]: https://github.com/bitcoin/bitcoin/issues/6578 > [2]: = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010535= .html > [3]: https://jonasnick.github.io/slides/2016-zurich-meetup.pdf > [4]: https://eprint.iacr.org/2014/763.pdf > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlr9M5YACgkQHrd2uwPH ki02mw/7BQlDmgxdzkVIYXCoF1twgt55e6OrDynxeyYaJome/U/6zA9LQVzTs8e8 Z1GDXymV2UNYcH8hLQHeXIH4dkkav+rZTszPtW3iu1JoOoFPb8/RBQhcd6OPHjSk nzgqoT86DjZ12AnGWyA7m8QN/6pnr9TPHBuCpcMcPA0l4lSBlpfb46ab17yZRZIw rvS9EYZymCGx4ioNdyqbvKlLXR+kK21mX547Y+L+tJjSJic/soXaqMU49zngHOyz 3EuQI/aZprdD5AZfsdcyGAcE6i9QLpsSml6n8sLKQAZmi7KKxgiqh9QSA2A0wFBU mw6TTDZCL4cT9RG5VbjfIkZ1Gh7B38J5jAMg7F/S79K+v0U3d6BkBq8+mEfsL/2H 0FYpVDF0DZTyu+1+hppmnXV/UacsKPVXSEPpq2OtZ1ADa0yKxivFLkJUhBcUvaat no4zhb6lQ3DApWaJGEOI+XvHNMpdsqw7xe3jOjeim7WNn358FJcORetNSH6+kch0 nd3rNydyZP3xdHMOTirkOhMMiQGQkJ0q8HlE4Ty6ihnIItH6ALIOyHlxFwqVt1uZ 0gRQG/kpIsG8hISpNzuGlf3VgFO6WlIpWAMR2l4JdzFmHq7QJU+UadOtxwICBesy cM0mgvve+Kn78DCiYsyFsw/Ubl4c+satl62RM3BGrxpDqyYsEuo= =lvQU -----END PGP SIGNATURE----- --Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001--