When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies

[DanGould]

When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies

source

Meeting Notes

The paper's two main contributions

Intersection attack of cookie + address cluster can MAJORLY identify clusters

If you have 2 payments, you get an exponential increase in detection rate

Questions

Can wallet fingerprint intersections (like ishaana's work or achow101's rust library) be used to make these assumptions even stronger?

Can we apply each of these "layers" to metrics code to give good open source heuristics to both clients to make spending decisions and explorers to attempt to explain flows?

Is the "legal uncertainty" that compelled merchants to use payment processors the same as today? I take it this was an Aug 2017 paper, right before FinCEN released guidance on who and what was a money transmitter and that concern may be alleviated today.

Certainly some of the leaky metadata problems, like HTTP plaintext requests are largely mitigated by default in modern browsers today.

How should the interface look

Coin Selection in e.g. Bitcoin Core is tightly coupled to the consensus transaction data structures. Our interface ought to be generic enough to work with simulated data that doesn't care about e.g. signatures, but can be easily mapped to from real consensus data. This is in contrast to Felix Maurer et al's cja analysis program.

We need to be able to bring in predictions and simulations, not just consensus data.

Could we apply this generic architecture to try_preserving_privacy and avoid_uih in payjoin as the beginning of a separate metrics crate?

@nothingmuch suggests using the petgraph crate for to apply these layers to a graph of transactions where transactions are vertices and coins are edges.

It seems that Algorithm 1 and Algorithm 2 in the paper could be implemented with some generic function that takes a parameter for e.g. mix detection and e.g. change detection.

Layers could be things like the true analysis based on a descriptor, or the assumed change based on amount heuristics, locktime height, script type, etc.

Other Miscellaneous Discussion

We discussed fountain coding in the context of Private Information Retreival (PIR) as in The Spiral Blyss block explorer and how where typical lookup would be $O(1)$ PIR tends to be $O(n)$ in compute time and disk access, though that can be improved by a compact block filter + additional special index. Apparently this can be optimized with some erasure coding which can be thought of like fountain coding (?)

We also discussed expander graphs as the desired outcome for a privacy preserving transaction structure, potentially using overt "lucky" coin selection. More details can be found in these CoinJoin robustness notes

Multiple interpretations

Ideally batched transactions can have multiple conflicting interpretations

1. adversary clusters everything together when it gets batched, mistakenly
2. adversary notices coinjoin and tries to guess payments through them
3. adversary mistakes payjoin for self-spend coinjoin

Coin selection could be applied using each of these models and choose a coin that introduces the highest conflicting interpretations based on your history to best preserve privacy.

@0xBEEFCAF3

[nothingmuch]

If you have 2 payments, you get an exponential increase in detection rate

For $n$ payments, as $n$ grows linearly the number of the candidate clusters decreases exponentially, they observed that for JoinMarket transactions often 2 payments was already significant

Can wallet fingerprint intersections...be used to make these assumptions even stronger?

Note that this is two separate but complementary things, wallet fingerprinting can be used for clustering, and intersection attacks can be done to attack coinjoin privacy by intersecting pre-mix clusters, fingerprinting.

We discussed fountain coding in the context of Private Information Retreival (PIR)

I mentioned fountain coding as a useful intuition pump for a recent PIR result, I believe it's this paper: https://eprint.iacr.org/2022/609.pdf and because of potential applications to a non-PIR based approach for improving compact block filters