I came across this chain analysis software because I was reading this paper of the same name.
It looks like they start by tagging a transaction based off whether it looks like it has been in a coinjoin and what kind:
That isn't exactly fancy or new or anything.
The next step is that they try to do grouping based on destination addresses:
Destination transactions are typically very private because they spend mainly mixed outputs. Nevertheless, when mixed outputs from distinct CoinJoin processes are co-spent, some destination transactions become unique. The similarity measure introduced in [3] takes advantage of this property to locate destination transactions that are likely to have been created by a single entity. Dakar implements this similarity measure. On the transaction page of a destination transaction, a list of similar destination transactions can be generated.
As far as I can tell, it's not like tools like this have any new ways of disentangling coinjoins, but they certainly do have the ability to look at inputs before the coinjoin and inputs after the coinjoin and do their best to make assumptions based all available data.
This screenshot shows the workspace and CoinJoin transaction heuristic feature. Lime green nodes are destination transactions, the blue nodes connecting to the right of the destination transactions are CoinJoin transaction heuristics and the remaining green nodes to the left of the top destination transaction node are mixing transactions. The side bar shows the currently selected CoinJoin transaction heuristic “Reverse Lookup by time”. This example illustrates how connections between transactions can be observed. Additionally, it shows that results of CoinJoin transaction heuristics depend on the connected destination transactions: the top destination transaction has a low anonymity set, while the bottom destination transaction has a higher anonymity set.
So: the moral of the story is mixing isn't the end of the privacy journey: you really really need to think about how you spend after mixing. For instance, if you use coinjoins and you want to preserve your privacy, you also probably want to make sure your cold storage is generic. Sending your mixed outputs to some fancy multisig setup that is easy to spot on chain is a bad idea. Spending the mixed coins in any repeated way is probably bad too (you also move them on the weekend, or always to a spending wallet that has certain characteristics).
One thing that gave me some hope is that this software wouldn't necessarily disentangle payjoins.
I'm pretty curious about tools like this, but it seems like I may need to get a better machine if I'm going to give it a whirl:
Serving the Bitcoin blockchain and the CoinJoin transactions of Whirlpool and Wasabi 2.0, the persistent storage occupies 2.4 TiB and the in-memory graph requires 7.7 GiB. The initial data ingestion, clustering, and classification require high I/O and CPU resources, while running the analytics modules uses a low amount of resources.
This is from their github readme:
Dakar is a blockchain forensics application, focusing on the analysis of CoinJoin transactions. It consists of a backend implemented in Go and web app written in Vue 3 with the Vuetify UI framework.
The backend ingests blockchain data via RPC connections to blockchain clients and performs transaction classification and address clustering on it.
The web app allows exploring the ingested and transformed data. Additionally, graph based editor enables viewing relationships between transactions and address clusters. Several CoinJoin analysis modules are available: heuristics, transaction similarity measure, mixing activity overview and more.
On my list of ways to spend spare time is to get dakar and bithypha (#1354357) running and really sharpen up my chain analysis skills.
Payjoin can also reveal the amount transacted, change address etc. if not done correctly. Also it involves different trade-offs in which recipient has to share the UTXOs with the sender.
good points. Is this project something that had already crossed your radar? Or have you had a chance to experiment with it?
This is the first time I am reading about
dakar. Thanks for sharing the link. Although such analysis won't work for payment pools (with musig+pre-signed txs or covenants).This is why I'd like to have mix-out to
ln funding tx.What is Stacker News?
It is a social media platform intentionally created to enable a P2P V4V BTC denominated community.
Originally Stacker News (SN) custodyed sats on behalf of participants but the threat of government regulatory prosecution on the pretext of money transmitter forced a move away from the custody of sats by the platform to the platform enabling participants to send sats via their wallets.
To achieve this participants need to attach wallets to both send and receive sats.
Where participants do not or cannot attach LN wallets transactions will often default to Cowboy Credits.
This change was a compromise forced by the threat of government prosecution.
The difficulty of attaching both sending and receiving wallets is moderate- it takes some effort and newbie or non tech people may struggle with it, but most competent Bitcoiners can succeed in attaching wallets and thus enabling sats denominated P2P transactions.
But a number of Stackers have chosen not to attach wallets- in particular sending wallets which enable you to send sats into the SN community.
Very few have attached just a sending wallet- many have attach just a receiving wallet.
Those who only attach a receiving wallet can receive sats from others but cannot send sats into the community. They may feel that as content providers they have no need or obligation to send sats into and within the SN community. I disagree.
Where these receive but not send (horse but no gun) Stackers proclaim to be Bitcoiners but refuse to enable a sending wallet they are demonstrably hypocrits. They claim they want to build and grow the BTC LN MoE network but they cannot be bothered contributing toward that growth by attaching a sending wallet and demonstrating they are not just talking, but are also walking and supporting a sats denominated platform.
If we do not use the LN wherever and whenever we can it will not grow and develop.
Some claim it is too hard to attach wallets- its too hard on their self custody nodes or wallets- this just highlights how much work the LN still needs before it is capable of anything approaching 100% reliable MoE capability.
But the best way to grow and strengthen the LN is it use it – despite its remaining flaws and glitches.
When wallets are supported by people using them they receives transaction fees and can develop liquidity and systems further.
When LN wallets are not used the LN decays- it does not have the usage and fees income to grow.
So when self proclaimed advocates for BTC and LN refuse to attach wallets (especially sending wallets) I see hypocrit.
I will continue to see hypocrit until and unless someone can explain why I should not.
Calling me a Nazi, trolling and making fun of me crudely seeking to avoid the issues I raise will not stop me from asking why are you claiming to be a Bitcoiner but refusing to attach wallets and use the LN here where we can help it grow.
Now some are deliberately concealing their wallet status, as if this is about a right to privacy.
Concealing your wallet status means nobody else can verify whether or not you are serious about using BTC LN, or whether you are just an all talk no walk hypocrit.
Do not trust- verify.
What about this fundamental principle do they not understand?
And then they talk about 'content' being more important than whether or not you have attached wallets - in this context the intentional lack of attached wallets undermines your credibility as your actions do not match your words.
Your submitted content may be great, but you as someone claiming to be a serious Bitcoiner are undermining your credibility and the credibility of your content by being a hypocrit.
Your content, is tainted by your verifiable hypocrisy.
SNs needs both good content providers and those who pay for that content if it is succeed.
I am more in the latter group than the former but both are required overall or the model does not work.
So as a net contributor of sats and thus a net consumer of content I object where content providers refuse to engage in the P2P V4V ethos by refusing to attach both sending and receiving wallets and I will both withhold my contribution of sats and sometimes downvote in response.
V4V needs to work reciprocally or it will not work at all.
The content providers need net sats contributors/content consumers who send sats into the platform, or the entire platform fails.