I’m concerned clients only performing step 5 (fetching transaction data) in response to untrusted data from step 1 (tweaks) and step 3 (pubkeys). If a client fetches all three pieces of data from the same server (or from different servers that are colluding), the server can potentially unmask users in step five by lying in steps 1 and 3.
For example: Server operator Mallory wants to discover the IP address of a user with SP address x. Mallory creates a fake payment to x, giving her a tweak and an output that indicate a payment to x. Instead of creating the tweaks and filters for the next block honestly, Mallory creates them using only the fake payment, distributing them to all of her users. The only user who matches on that fake data is the owner of x, so that person is the only person who performs step 5 (downloading transaction data); this reveals their network ID to Mallory (e.g., their IP address if they use a direct connection).
Downloading tweaks and filters from different servers doesn’t help. Even if we can be sure the servers aren’t colluding, whoever controls the filter distribution server can always force a match by lying. I think whoever controls the tweak distribution server can also force a match, but I’m not 100% sure on the EC math to do that.
What I think is best is similar to what Wasabi does with its custom BIP158 implementation:
- Client downloads untrusted tweaks and filter from the server (ideally using something like an ephemeral Tor connection)
- On match, client downloads the corresponding full block from a random full node (ideally using a different network identity, such as a different ephemeral Tor connection)
Given the large number of block-serving full nodes, this reduces the chance that the client connects to a full node controlled by the server. Additionally, given the modestly large number of existing BIP158 clients that are already occasionally downloading arbitrary blocks from full nodes, even if the client did connect to a full node controlled by the server, the server couldn’t be sure that the peer requesting a particular block was the peer it was targeting. This is true on regular IP, with increased privacy guarantees available to users of Tor ephemeral addresses or similar protocols.
Thus I think there’s a lot of advantage to using full blocks and connections to regular full nodes in step 5 of this protocol. The downside of full blocks over minimized blocks is increased bandwidth, but my guess is that most SP users will receive less than one SP payment per day, so the bandwidth cost of a full block is less than 4 MB per day. Those receiving more payments can probably easily afford the increased bandwidth costs (about 600 MB/day in the worst case).