Nostr Web Client

Very great points, thanks for clarifying with so much nuance.

Do you think the false positive rate of block filters provides a reasonable defense even if Tor is broken? Blocks that do not contain users addresses are downloaded too.

David A. Harding 2y ago

It depends a lot on the threat model. Let's consider two scenarios:

1. Mallory is monitoring all traffic to a given IP address (no Tor, or Tor is completely broken) and wants to learn which outputs it controls. Every transaction downloaded by that IP address which doesn't belong to its wallet increases the anonymity set of the transactions which do belong to that IP addresses's wallet. Because BIP157/8 involves downloading whole blocks (typically a few thousand transactions), it would create decent-sized anonymity sets even if there was never a false positive; adding the occasional false positive block just improves that.

By comparison, Bitcoin Core is like having a 100% false positive rate; now the anonymity set is every transaction in the entire best block chain.

2. Mallory knows a Bitcoin address and wants to find the IP address of the wallet controlling that Bitcoin address (again, no Tor). If Mallory has the ability to surveil IP addresses that the wallet might be using, she can spent a tiny bit of money to that address to get the wallet to download that block. Many other wallets will also download that block, either because they had transactions in it or because of the false positive rate, so that's the initial anonymity set. Mallory can then send another tiny bit of money to the address. The wallet she's interested in will download that new block but many of the other wallets which previously downloaded it won't (they didn't have a tx in that block or it wasn't a false positive for them). This shrinks the anonymity set. Each time Mallory sends a bit more money to the address, the anonymity set shrinks further, until she finds the IP address.

By comparison, Bitcoin Core is immune to this attack. It downloads every seemingly-valid block unconditionally.

Reply to this note

Please Login to reply.

Discussion

Max 2y ago

2. is an interesting attack I did not yet think about, thanks!

Is there some math to calculate how much your anonset shrinks with each address reuse block? I guess it depends on the false positive rate of the block filters, but how does this overlap with other users' addresses?

And sadly you can't even ignore those low value coins, as you only learn about their value after downloading the block.

You could not to download blocks on reused addresses in general, but that means you might miss a lot of value from "honest" address reuse transactions...

David A. Harding 2y ago

Unfortunately, with stock BIP158, you can't avoid monitoring for reused addresses until you've spent all the coins you want to spend that you previously received to those addresses. That's because BIP158 "basic" filters use the output scriptPubKey to track both receiving bitcoins and spending them.

For example, Alice receives some bitcoins to bc1pfoo in a transaction in a block. The filter for that block commits to OP_0 foo.

Later, Alice spends that transaction output. The filter for that later block also commits to OP_0 foo.

If, in between those two blocks, someone else sent bitcoins to bc1pfoo, then the filter for that block would also commit to OP_0 foo. It wouldn't be possible for Alice's wallet to determine whether the filter made that commitment because new bitcoins were received to bc1pfoo or because of a spend of the bitcoins she had previously received.