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 563BDD6E for ; Sat, 2 Jun 2018 13:16:18 +0000 (UTC) X-Greylist: delayed 00:32:45 by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9F7E6DB for ; Sat, 2 Jun 2018 13:16:17 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.89) (envelope-from ) id 1fP5sZ-00088N-Ow; Sat, 02 Jun 2018 12:43:31 +0000 Date: Sat, 2 Jun 2018 08:41:57 -0400 From: "David A. Harding" To: Jim Posen , Bitcoin Protocol Discussion Message-ID: <20180602124157.744x7j4u7dqtaa43@email> References: <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fzwwefg5shnzqbip" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size 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, 02 Jun 2018 13:16:20 -0000 --fzwwefg5shnzqbip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote: > Without the ability to verify filter validity, a client would have to stop > syncing altogether in the presence of just one malicious peer, which is > unacceptable. I'm confused about why this would be the case. If Alice's node generates filters accurately and Mallory's node generates filters inaccurately, and they both send their filters to Bob, won't Bob be able to download any blocks either filter indicates are relevant to his wallet? If Bob downloads a block that contains one of his transactions based on Alice's filter indicating a possible match at a time when Mallory's filter said there was no match, then this false negative is perfect evidence of deceit on Mallory's part[1] and Bob can ban her. If Bob downloads a block that doesn't contain any of his transactions based on Mallory's filter indicating a match at a time when Alice's filter said there was no match, then this false positive can be recorded and Bob can eventually ban Mallory should the false positive rate exceeds some threshold. Until Mallory is eventually banned, it seems to me that the worst she can do is waste Bob's bandwidth and that of any nodes serving him accurate information, such as Alice's filters and the blocks Bob is misled into downloading to check for matches. The amount of attacker:defender asymetry in the bandwidth wasted increases if Mallory's filters become less accurate, but this also increases her false positive rate and reduces the number of filters that need to be seen before Bob bans her, so it seems to me (possibly naively) that this is not a significant DoS vector. -Dave [1] Per BIP158 saying, "a Golomb-coded set (GCS), which matches all items in the set with probability 1" --fzwwefg5shnzqbip Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAlsSkJUACgkQ2dtBqWwi adOfTw//XgeBJJ1v9sFcbfOn6KvcA3SrnRuyljoJwqcwt5VM7LTkuMC+pISuPXdc feF8GiW2G7uY3kPwkDSniDTqZTgcT4iG0mg81WEMEweAQ9+3z31mOzqzJiCG5T8E y+YdM2jDl9DD06qkReM1jJyBqN2eEtiwijVaakEfU7UguvyDPsWlXnYzelr6KBSc 7DzSmpn6GAVBBNnetu3C1BBghkcEm8EIj2UmK2hJxA1bJ7CdZXiYsF8kk76Vt2l6 sQ9jSF+mtOS4Ws8lkVKohh5nv7s55STpnJmcU/042BWr2ywctizSYmeIeDHJtdH+ PFbRYwE9wZZ6aTSjQlf8bdcq6DtJRlgQdYKo3gZ4brzNHiPZXId1qCKHFg0qZggc AoJU9Eyy7oLSRYWxqT90kuLRyltmEtkrZgsVBwtpK9M126E0jtCRR/dnaGARhY2x zZFIemNO6V84+Byi2S2tZhkzTDmlwvsYL+YVxw/crOUTlDWxV72m5nsodxd8adcs Vt3H9MEAZulhGMj57q8XgzL0mJ3L2jeG9WGkDDZFkGkpxXkXc0hW02W16reKT+cY YepTNiVqHaz3Fgr7cY5bC2Iuypmv5qO8mm0z5Fxe5/Mi8z0feF+aGtfhsutO3EsM IKgcFrZr8ONQhP/iJvTLbhzEgtN4PaDYetf0maHiqAVJNG7eC7A= =hptV -----END PGP SIGNATURE----- --fzwwefg5shnzqbip--