Reducing Privacy of CoinJoin Transactions: Quantitative Bitcoin Network Analysis #581
DanGould
started this conversation in
Study Club
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
source: CoinJoin_paper.pdf
Network analysis
Novelty was CoinJoin identification and separation of$UG$ from $UG^{-CJ}$
given different heuristics that mostly agree with each other, how much can we learn about how to cluster better, and can we use that to attack payjoin privacy
look at how well clustered inputs are, then, if you see a normal payment tx but see inputs that likely belong to another cluster, how reliable is this approach to try to ID a payjoin (and break anon). You could also use it as a cross-validation technique. Calls back to Random Forest Classifier.
For Boltz, what are the classifications for them? If they have a special swap signature, does payjoin help them at all? Is it separate from privacy and merely a fee-beneficial relationship? Yuval says it's strictly better because ultimately less info gets on chain.
River's summary:
Was this one of few papers attempting to track people rather than preserve user privacy?
-- it's useful for diplomacy
Network analysis
preferential attachment: a way to construct random graphs that have power-law degree distributions. (similar to social neetworks, road networks, etc.)
Low time for user lifespan could suggest users have disjoint clusters because e.g. they spend all of their coins at a time.
average user cluster age of 5.2 days doesn't necessarily suggest privacy, it might just suggest users have multiple clusters that don't collapse, or something else.
get paid -> make lots of payments takes longer than
get paid -> cash out to an exchange
Armin: How does the network analysis tie into cluster collapse?
Yuval: if you look at clusters w/o accounting for CoinJoin, degree distribution skews
Re: performance of processing
Dumplings is 1000x too slow.
There are implementations that parse block data directly like they did in python, in Go, and in Rust.
but how do we apply this to light clients?
Would be good if it could use block.dat, or data at random, and should be used for indexing and of course be mindful for privacy. We can come up with goals
Dan brings up because we need deliverables. Yuval wants to wait until denial of service.
BIP 77 Edits
All reactions