Topic: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths! - page 3. (Read 1704 times)

A segwitv0 output is 31 vbytes, but a witness input is around 68. That's 99 vb, multiplied by 37.5 = 3712.5. Yes, it is less than I wrongly calculated, but it is still waste of money for such a small output.

I'm good at quoting old posts as well:

B-b-but, I thought this ethos was unacceptable.  


I know, I know... Just another confusion in the name of privacy!  

BlackHatCoiner, you still haven't followed up on our original conversation about me linking Whirlpool addresses together:



Your math is wrong:  At 37.5 sats/vbyte, it costs 1163 sats to create a segwitv0 output (31 vbytes) and 1612.5 sats to create a Taproot output (43 vbytes).  Smart WabiSabi clients make sure to choose outputs that aren't dust: https://github.com/zkSNACKs/WalletWasabi/issues/10675

However, Whirlpool clients create traceable dust outputs that cost more than their value to create.  I reported this to Samourai, but the bug report was deleted without comment: https://web.archive.org/web/20231025112756/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/461



As you noted already, the service does not choose the addresses, users choose their own addresses:

Come on, kayirigi. Get over it, it's clearly the user's fault!  

What's dust? Gimme my 5000 sat that costed more than double that amount to be created!

Oh! It's supposed to confuse the observers of the coinjoin, that explains everything! Let's start reusing addresses in both inputs and outputs then, as in Wasabi 1.0. That will definitely help, because we will confuse chain analysis even more. Why kind of a clown service reuses addresses in both sides in the first place? That will leave them so speechless that they will give up!

As you demonstrated, you weren't you able to identify the inputs owned by the user who merged their outputs in WabiSabi.

WabiSabi exit: https://mempool.space/tx/9273410e2994fa02fb1baa071d84a44fb4ad12ceba50a46eadfd24cf0dd7efa6
WabiSabi entrance:

As I demonstrated, I was clearly able to identify the inputs owned by the user who merged their outputs in Whirlpool:

Whirlpool exit: https://mempool.space/tx/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db
Whirlpool entrance: https://mempool.space/tx/63679c9ec82f246811acbab0c04cc0fc77ba050e1b6c23661d78afcfc13cf8aa

Only WabiSabi preserved privacy in this case, while Whirlpool leaked the origin of the funds.

So exit merge on Wabisabi good. But exit merge on Whirlpool bad. LOL. And you think people believe this BS from a Wasabi worker?

And you ignore 100% deterministic links. And address reuse. 

Wabisabi is a scam.

BlackHatCoiner, you merited a post above but you haven't responded to your previous conversation:

This is exactly the sort of confusion a coinjoin is designed to cause  You mistakenly thought that multiple inputs being spent together meant that they were linked to the same owner, but a coinjoin has inputs from multiple owners in the same transaction!


Here is the exit merge transaction spending 2 outputs from the coinjoin worth 0.1 BTC each - 9273410e2994fa02fb1baa071d84a44fb4ad12ceba50a46eadfd24cf0dd7efa6 - let's analyze them:

In the coinjoin, there are 13 outputs for 0.1 BTC:

bc1qzy2dlcau905jwaktrlnqd7q2uu8m6296xe0y0t <- Exit merged
bc1qykz79d67prjv73wej032kreyysumvg54wlqsc3
bc1qfdt9na0vqu94y0ltz97fg6ep0nztqrlhj4e6as
bc1q26vktzc3uqhld6kgf0c0zgldh4t7wp665kfwm7
bc1qvged8zxdpcsxc3qe2pl62lsl3neprltrvtspn3
bc1qsl2sp0t87rsau6tusy465p9e5vq7r9y0ldns6a
bc1qjpmncaadtk5ef32km44xa5z0mzsden78ev66ws
bc1q5t00axlmeyg7crkq4rlh2qevdz8lcud8gl2q8h <- Exit merged
bc1qe3s0vlsvu3rhd7w7dsswsgdj5k2t99e0f90a9n
bc1q7whl0n3dvu5n3tjqd4g4r7antz70t96mhepn6v
bc1q7cnu23w5rxlktdhm7322y7spe8kyj98dl6stwf
bc1pdu3xkqcpwd6x9uhhy5rh536nevj9vzqkpqmnqjqkhuwpqp9zgrssjh3gwa
bc1pkmkkpug5z2w6pn80kwlyev7v5nw6rukjae4cha2mz6vusz0ef98q5vcv9d

By consolidating two inputs for 0.1 BTC in the payment, the owner retroactively reveals a coinjoin output value of 0.2 BTC.  Does this cause him to lose any privacy?  Let's check the original coinjoin transaction to find out...

In the coinjoin, there are are 9 outputs for 0.2 BTC:

bc1qxcfcgdqey4yc3cqjknea2spe8mw2r0k7n083t2
bc1qwezuexwx4lvafeg34ctzpny64fu3t9w8ngtngg
bc1qs3ztep3w80pm3wz4htj2h9x4ewdug4hzaphfve
bc1quqzcseygmad87g4plgf9yuxzss5r5q72w9g3w2
bc1qu7uj5tcdj5s2e23t08v0rsneejvfd6n0qrxf36
bc1qu77gevtnq6uky0vpjpl2ru96lus58p38qmpywc
bc1p2mzlp34rqsyv7u28y6xdpypqapc8aeeuczuaaqzkv9snmnsenj2sw0uny9
bc1p742nnv0774t5gk8lt72t02wuupapt47dx00ddsq45zl9gedcw22qp3ayg2
bc1plmzmhejjuqykvnf00mue54egap3kjtl5qtcdzf4q6k7v87q34lqs37z3t5

The user stayed anonymous when merging his two 0.1 BTC outputs together since there's many possible ways to create 0.2 BTC as an output from the inputs of the original coinjoin.  This transaction demonstrates how the "smart clients" arrange their output values so that merging smaller matching outputs together results in creating a larger amount with additional matches!

This exit merge proves that even smaller denominations than 0.1 BTC are now also possible combinations that would add up to 0.2 BTC, adding even more anonymity!  Let's check the original coinjoin transaction again to find some...

In the coinjoin, there are are 13 outputs for 0.05 BTC:

bc1qyttl3f9wu2zm3dwnytavs6eqk00glc3xng43ea
bc1qye0g8qdjdl48c5hx7a69t5ekcgcemfrhx9z6sr
bc1qxrgu0lv0ps50c9nf2efjq5zfdfruxejmfu8g8y
bc1qgpwc5803au9cs95u38yz64jhdjrkpp4j249n9u
bc1qt2wugrvm5nts263he4aj2ky2pghhdl90j0lx03
bc1qvzanwhhyf2tfcds3rts958jun84ves3xtc3gcp
bc1qvgmnh5fzrqzx7uhhrcw6emzmktj4atqpn7ev9m
bc1qdm9ae8rq0403ga5rshvw4vjd507t8chu4fn40k
bc1q0ltpdzchc6eeytaafl7muhscdfejr2w269a8xl
bc1q3z5cj7sx53lq8sqdkmflce0dzsaj6437zzqj3p
bc1qhm4cd97znryr6rx4wqrsjj2shcpl44hhmsf8hz
bc1qcww2qypj47vz52uw5y8m7cn7y8vvfxx7tnrajq
bc1pncyek7s2m3tc9kwkswqnja8309gtmjgsykpa5jyahhv7yuavyugqlfpee5

On top of the possibilities of creating one output for 0.2 BTC, or two outputs for 0.1 BTC, it's also possible a user with 0.2 BTC on the input side created 4 outputs for 0.05 BTC instead!

___________________________________________________________________

How does this compare to Whirlpool exit transactions?  Here's the kycp analysis of the Whirlpool exit transaction I traced in the OP: https://kycp.org/#/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db

All 20 postmix outputs merged were a direct descendant the same premix transaction, making it trivial to unmix.  Unlike JoinMarket or WabiSabi, this user is not in control of remixing, he is dependent on the Whirlpool coordinator to push his coins deeper into the pool.

https://kycp.org/#/1ca4743bd12bc54cd19233f0807ae8b7faec7fdce695f72f345b99d0200ef3d5

15 address reuses
13 exit merges
233 inputs linked
236 outputs linked

Cya privacy! Let's do another!

https://kycp.org/#/ad5516f70697af7c9b14297bb4eb1249bee216b7976b7c50f2369a89afb86975

2 address reuses
2 exit merges
This one with extra bonus of 100% deterministic link between input and output!

Cya privacy! And extra extra bonus of HUNDREDS of outputs ground in to dust. 5000sats? 6561sats? Losing money for Wabisabi coinjoins which don't work!

You are lying, the document you linked was published a year before the WabiSabi protocol was in production.

Feel free to try to trace a WabiSabi coinjoin yourself, no one else has been able to do it:

Chainalysis can demix Wabisabi protocol and do this for OFAC. Wabisabi is the only one of three coinjoin protocols which can be demixed like this.

Here is government contract with Chainalysis
https://archive.is/1zU9t

Yes, it doesn't appear the docs are extremely thorough for the coinjoin plugin.  Here's the big red /!\ warning message that appears in BTCPay Server if you try to coinjoin with Tor off: https://github.com/raspiblitz/raspiblitz/issues/3729



Whirlpool clients have Tor disabled by default, so I opened an issue to get a warning added to Samourai Wallet about the privacy leak, but they said that any PR that adds this warning will not be merged: https://web.archive.org/web/20230417145554/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458

There's 0 mention of keyword "tor" or "onion" on it's documentation though https://docs.btcpayserver.org/Wabisabi/. Although i didn't watch included youtube video.

Yep, I'm excluding any wallet level implementation details and focusing on the protocols. As you indicated further on, the most trivial way to forfeit privacy in this process is reuse the same IP address for each "identity" you assume:


Tor is used by default for the WabiSabi coinjoin plugin in BTCPay Server.


Yes, that's the section.  There's 0 marginal cost for an attacker to DoS a WabiSabi coinjoin round just like there's 0 marginal cost to get another plate of food at an all-you-can-eat buffet.  Since you will pay to transfer any UTXO you own at some point anyways, there's no disincentive for attacking with it before giving up ownership in the future.

In the JoinMarket framework, this 0 cost attack applies to malicious takers who propose offers to makers without ever intending to complete them.  Makers will reveal common ownership of their unspent coins to the taker, who never ends up paying the mining fees to mix that maker's coins. See https://reyify.com/blog/poodle and https://github.com/JoinMarket-Org/joinmarket/issues/156 for the defense against this attack.

That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack. At very least, BTCPay doesn't use Tor by default and in certain cases i expect to detect whether it's deanonymization attempt or network problem.


Is that from section 7.1.2? What exactly do you mean by marginal cost?

What mistake did I make?  Use a direct quote and I'll update it with a correction.

The saddest thing of all is that you don't even recognize your mistake, let alone show any remorse. It is pathetic.

But, I still wish for someone to stand by you in your time of need, someone who will love you no matter what.

I care deeply about Bitcoin privacy, that's why I spend so much time to educate people about it.


You don't seem to understand: Equal output coinjoins from JoinMarket, Whirlpool, and WabiSabi have a distinct on chain footprint that distinguish them from all other transactions regardless of whether those transactions are ordinals or not.


You can easily scan the blockchain yourself to identify any equal output transaction (including coinjoins) using this tool: https://supertestnet.github.io/coinjoin-explorer/

Here's what the footprints of each coinjoin protocol look like:

-JoinMarket - https://mempool.space/tx/c270b84767431eae0aabcd4f99f93f1d299518aebb7529650dbbf41815561d03
-WabiSabi - https://mempool.space/tx/d465033214fd2309dcce5a90c45fcaa788aa4394ee36debe07aad8d8a37907d2
-Whirlpool - https://mempool.space/tx/3cef999a3c006be772f7f63fc87b718cd01146ab593644e0eeb3d61e753f02b8

Merely knowing a coinjoin transaction has occurred does not actually make it any easier to determine what happened within the coinjoin transaction.

This is my last post to you since you don't seem to care and I am tired of wasting my time.

You are 100% correct ordinals has absolutely nothing to do with coinjoins.
Ordinals are filling blocks with transactions that are obviously not coinjoins. And the rest is Crateology.
https://en.wikipedia.org/wiki/Crateology

As I said take out ordinals, take out known TXs, take out what else they know from other services and you have a very small pool of txs moving at the moment.
Keeping an eye on all of them and figuring out what is going on where is a lot less difficult then if all the txs in blocks were 'real' transactions.

Could 1 person do it looking at a list? Probably not. Can a lot of people with a lot of computing power and resources following all transactions do it. Probably yes.

You also seem to think that there are not a ton of tor nodes that are not run by and fully monitored by the government too.

-Dave

Ah, I misunderstood: You meant this cost is to set up the attack, not to set up the coordinator itself.


A is the input registration phase, B is the output registration phase, and C is the signing of the complete transaction.  Phase A always ends before phase B begins, which always ends before phase C begins.  Where's the problem?


Ordinals has absolutely nothing to do with coinjoins.

1) Because all the other coins in the coinjoin would be that persons. That is the point.

2) Later people reconnect and sign is the problem. It's usually (not always) not later, it's then and there. a->b->c tend to happen in somewhat real time. So now I know what to look for. And with blocks being full with ordinals at the moment you can probably eliminate 80+% of the TX, take out what are other known addresses and transactions. And the few dozen or hundred at the most can be sorted through at the governments leisure.

-Dave