Replies: 1 comment
-
For
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.
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 |
Beta Was this translation helpful? Give feedback.
-
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
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
Beta Was this translation helpful? Give feedback.
All reactions