rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2018-06-02 📝 Original message: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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180602/9556f60f/attachment.sig>