Anyone care to tell me the payment amount in this transaction? 🤔

With certain contextual clues you should be able to narrow it down a lot, but if you can do that you'll also realize this will be VERY difficult in future ...

· · Web · 5 · 1 · 4

One wrong answer from a bitcoin expert already :)

@waxwing 0.00002701 btc ;-)

i assume the 0.01379728 output is change given that it's smaller than all of the inputs

this implies to me that the payer potentially has any subset of the inputs, which means Bell(5) possible values ranging from 0.06002516 (0.07382244-0.01379728) to

i'm not seeing any way to narrow it down, although many of the inputs appear to be change from different coinjoin transactions so arguably traceable at least 1 tx further back?


Good stuff :) First good because you identified UIH1 is violated (see for definition). That means that realistically if it is a payment, then you know which output is change. But it doesn't violate UIH2, so it *is* plausibly a normal payment.

On the actual payment amount, you may have overcomplicated things a bit :) The exact amount is actually rather trivial to see, but that's just me being lazy, it could have been harder. (1/2)

... Re: the inputs, there are some context clues in there, but again, that's dependent on the exact example. In general this will be hard to see. (2/2)

@waxwing OK, revised guess is that receiver contributed
0.03211415, and payment amount is 0.6

but this is based on a heuristic that is hard to justify, namely that payment amounts typically have low entropy in their representation, which doesn't seem robust ;-)


Yes; re: entropy, well sure, this is an almost uninteresting way of identifying exact amount, since it's trivially avoidable, so ofc I agree there. But also there's the question of tx fee, which is kinda interesting here: it's always just been assumed that sender pays it, but when receiver gains economic benefit of utxo consumption, it could be argued it should be shared (it wasn't here).

Anyway, good job of analysis :)

@waxwing fwiw this intuition about amounts was the main motivation for the preferred value series idea.

the intuition behind using a preferred value series is that all amounts become very low entropy and so become less distinguishable and more easily mixable

currently i'm/we're still stuck trying to come up with an anonymity set metric (realistically a lower bound) that is actually scalable to transaction graphs, in order to sufficiently motivate the removal of zerolink's post mix restriction

@waxwing i should provide a link to that writeup shouldn't i:

this is specifically written as an amendment to zerolink/wasabi, but the idea of using a narrow set of denominations i think may benefit all coinjoin protocols, especially if their transaction graphs are connected


Strange how the inputs come from some sort of relay tx that didn't pay any tx fee. Parent pays for child perhaps?

But speaking as a judge or prosecutor, it clearly shows the purchase of 0.63211415 BTC of illegal drugs, and change of 0.01379728 BTC. 🤣

Would love to hear an expert dissection / analysis though.


I think you must have read something wrong? All the input txs paid a fee.

@waxwing Ah - yes, I misread the block explorer. I don't have too much practice at chain analysis.

@samouraidev Yes, very good example; violates UIH1 (which will often be the case), but it's of no consequence, because it doesn't violate UIH2, so it looks like it could be an ordinary payment of 0.07842... ; and unlike my example there isn't some obvious giveaway with a rounded amount.

In practice I think there is basically zero chance that analysts will even *consider* the p2ep possibility. By the time they do it will be increasingly obvious that "chainalysis" is basically broken.

@waxwing After @laurentMT ran stats on UI1, I didn't include it in the algo and I prioritised UI2. UI2 should be covered on our end. Of course, all of this is subject to fine tuning, as always ;)

@samouraidev Exactly, yeah, that's how I see it too. Good stats, very interesting.

@waxwing @samouraidev startup idea: Random Oracle Chain Analytics, a company which gives randomized (but consistent) attribution - siphon money from the legal system into privacy research in exchange for providing conflicting black box "evidence" to hasten the demise of this multi-million dollar industry. a win-win-win!

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!