Topic: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths! (Read 1249 times)

You are right you could argue that the maker or the taker switch their roll between coinjoins but joinmarket and whrilpool still would give a false sense of a higher anonset then it leads to believe. So it comes off as the makers being almost pointless and making the transaction fees not worth the effort. IMO I think wabisabi is a much better coinjoin system since all inputs are takers with unpredictable output spending. Wabisabi gets a bad rep for blocking certain UTXO's but I think this is a good thing because coinjoining with sanctioned UTXO's will label all UTXO's in the coinjoin as sanctioned.

When you look at a single JoinMarket coinjoin, you can often (but not always) determine common input ownership for the participants and track their change. However, this isn't a limitation that ever requires you to compromise your privacy because you can use the taker role to construct a coinjoin where you have only one input and one (equal sized) output.

Here's an example of a JoinMarket sweep transaction: https://mempool.space/tx/9c6479472e1f3b5861c86bc904d11814e715a84c21aa8d0dd0861e635555451f

You can tell this is a sweep instead of an outgoing payment because there are 9 inputs, 9 equal sized outputs, and 8 change outputs that can be easily connected to maker inputs. The taker's input was from bc1q2pcrqv8jshjalxdan9hdm6qsh0njtm7jxydct9, but there is no trace of his output since it could be any of the 9 values for 0.03846033 BTC.


Yes, common input ownership and toxic change are the same problems inherent to Whirlpool coinjoins as well. The main advantage JoinMarket has to defeat this problem is ability to coinjoin arbitrary amounts, so your toxic coins never have to touch each other. Whirlpool is limited to coinjoining fixed amounts (0.5, 0.05, 0.01 and 0.001), so every transaction you send or receive will require you to forfeit up to 100k sats in unmixable change in order to keep full privacy.

The second advantage JoinMarket has over Whirlpool is that Whirlpool cripples the privacy of users by requiring a premix "tx0" transaction. The premix conclusively reveals all the consolidated inputs are owned by the same person and links it with toxic change that can be tracked in future transactions.

JoinMarket mitigates this privacy leak by skipping the premix transaction and consolidating inputs directly in the coinjoin transaction. Here's an example of a 5 person JoinMarket coinjoin that consolidates 297 inputs: https://mempool.space/tx/63b28f5e17e03fef27795e1ea7fbf821e2d5f072098ffcef3d27b8b2d23ca719

This makes it difficult to determine which inputs belonged to the participant that created the 33677 change output and which inputs belonged to the participant that created the 44384 sat change output.


If 5 out of the 6 equal sized outputs created in the coinjoin end up remixing as makers in the future while the remaining equal sized output is spent in a unique way, the first guess someone would make is that the output that didn't remix was created by the taker. But, this is still a guess and not a 100% guarantee since the taker could have switched roles to become a maker, or a maker could have decided to stop remixing and spend their coins. So, you could have scenarios where all 6 of these outputs remix, or all 6 of these outputs are spent, or any combination in between.

I thought joinmarkets were still pretty easy to unmix. If theres only 1 taker and for example 5 makers in a joinmarket coinjoin it should be pretty easy to unmix them if you watch to see which output get used as inputs for more coinjoins then they are makers and if you can determine which outputs were makers then you can determine which output is the taker by process of elimination.

This is the same problem with samurai wallets whirlpool right?

Question for experienced JoinMarket users: How frequently do you participate in a remix as a maker?

LaurentMT confirms that Whirlpool's incentive model was designed to provide the least amount of anonymity possible: https://twitter.com/LaurentMT/status/1783589807668535563

Some Whirlpool users were rugpulled because they paid coordinator fees in a separate transaction from their coinjoin: https://mempool.space/address/bc1q6dxnvx3wm40e4rtmye6fwy9zmwnqchnz04pzaa

Mempool.space seems to have applied the "Coinjoin" tag to this Whirlpool tx0 transaction as well: https://mempool.space/tx/97a6b985f48c2faf4a3cb7c1e4b5a0ac230fd59aac33723101de9dd144bd735e

I wrote a blog describing how WabiSabi clients can avert future consolidation mistakes by preemptively remixing under certain scenarios: https://blog.wasabiwallet.io/exploring-secure-coinjoin-protocols/

This issue explains the assumptions a lazy attacker would make from observing spent coinjoin outputs and how to avoid imitating the known weakness of ZeroLink consolidations: https://github.com/zkSNACKs/WalletWasabi/issues/10565

Coinjoining takes time and block space, and since both are limited resources, the debate is consequential. No one wants to waste either.

Is everyone still fighting over which CoinJoin is the best in Bitcoin Land?

¯\_(ツ)_/¯

I believe it's not only about which CoinJoin tool you're using, it's also about HOW you use the tool. Simply, it's not enough to merely CoinJoin. The user has to do a lot more after the CoinJoin.


Both sides of the debate in the topic are probably right and wrong at the same time depending on the context.

I gave you some merit because at least you are trying smh

Another coinjoin detecting tool is mempool.space, it highlights coinjoins pending inclusion in a block:

Thanks for the resource.  Yes, this paper explains in more detail what I couldn't seem to get DaveF to understand:


This one, unfortunately, is not a good resource- It's a Craig Wright style propaganda piece that tries to steal credit from Satoshi and give it to a woman instead:


Satoshi's identification of this tracking method wasn't a "hint" and it wasn't "inadvertently", it's quite literally titled "Privacy" in the whitepaper. The author is simply trying to deceive readers into thinking this woman made a profound discovery when all she did was read the whitepaper.

Good reading on the matter "Heuristics for Detecting CoinJoin Transactions on the Bitcoin Blockchain".

They analyzed various implementations of Coinjoin including  JoinMarket,  Whirlpool and Wasabi (from 1.0 to 2.0), applied different heuristics to them and got some success.

Also, worth to read is the following -   "How a 27-year-old busted the myth of Bitcoin’s anonymity". - which shows that all depends on appropriate and adequate obstinacy of investigators,

I guess I didn't catch your point, can you refer to your quote and indicate what is lacking a response?  I'm still waiting for you to respond to my points above:




So the Whirlpool coordinator's output is easily identified. That's unfortunate...

Let's compare this privacy loss in Whirlpool to a WabiSabi coinjoin where the coordinator fee adds to the anonymity set: Which output is the coordinator fee???  https://mempool.space/tx/74254011886f8bcbc19269030a07d3e63cee242492f7a32818152e51995e6d31


You simply haven't looked into how coinjoins work at all since you are accusing WabiSabi of creating negative dust when it's clearly Whirlpool that's creating negative dust, and claim WabiSabi's Boltzmann score is worse despite not having calculated the score at all.  Numbers don't lie, but you do.

Avoiding my point, as usual.

Completely irrelevant and debunked already: https://bitcointalksearch.org/topic/m.63120005.

Because it makes a splash. Whirlpool has maximized the entropy, whereas in Wasabi there is address reuse, possible input and output collaborators, merges-- all of which would reduce the overall entropy.

---

At this point, I'm putting you back on ignore, because we're going on cycles, and you simply want to just say the last word. There is nothing constructive that I can make out of you.

I don't know what you mean by "A user is not warned from reusing an address", Satoshi very clearly warned that a new address should be used for each transaction:


If you never calculated the Boltzmann score, then why did you claim the Boltzmann score for a WabiSabi coinjoin is "worse"?

So, to sum up. A user is not warned from reusing an address in both inputs and outputs of their coinjoin, despite being a complete waste of both money and privacy, because the coordinator does not want to be "malicious" and prevent potentially malicious activity. Makes sense.

I don't work at Samourai, so this is a disclaimer that I have not studied Boltzmann analysis to feel competence and confidence, but it is an attempt to resist against merged input heuristic and to identification of linking between coinjoin inputs and outputs; attacks made by blockchain analysis that you're proudly funding, and which can de-anonymize Wasabi coinjoins as they say. Description of these metrics can be found in Samourai's repo.

I didn't repeat myself, this was the first time I've asked you why you would choose to create toxic change from coinjoining that causes privacy loss instead of choosing not to create toxic change from coinjoining to keep your privacy.


If you are using a second coinjoin to solve the privacy flaw of the initial Whirlpool coinjoin, then why not just perform a single coinjoin that doesn't have the initial privacy flaw so you can cut through these two transactions?


If this request is ignored, then the coordinator would have to propose a 5 input 4 output transaction to the participants that spends the value from the ignored output on the mining fee instead, or replace the missing output with their own address.


That's what I'm asking - I want to see this information that reduces the uncertainty for myself.  Using this coinjoin transaction, what information is revealed from these input and output merges that reduces the uncertainty?


So you're saying that WabiSabi is too powerful for the Boltzmann analysis technique to handle  

Repeated soundbite. I ignore.

You do not consolidate your private coins in the the coinjoin, but after it, using a mix partner.

Yes, it does. Alice can normally register her bc1qalice input, and the coordinator will refuse to create a bc1qalice output. The attacker can be ignored.

I said:

That does not mean I can de-anonymize the outputs with certainty, as I can with a 20 inputs 1 output transaction. I can only say for sure that there is information which can reduce the uncertainty, and which does not appear in Whirlpool. See yourself: https://kycp.org/#/323df21f0b0756f98336437aa3d2fb87e02b59f1946b714a7b09df04d429dec2.

Probably because Samourai's implementation of Boltzmann score's computation is not optimized; I just cloned their repo, entered a Wasabi transaction, and it's still loading. WabiSabis are very big in size, not even oxt.me has worked it out (TX ENTROPY is N/A in summary). Maybe I optimize it once I find the time.

Why not use WabiSabi instead of Whirlpool so you don't have toxic change and have no lack of privacy at all?


You can't consolidate UTXOs in a Whirlpool coinjoin, there are always an equal amount of inputs and outputs.


Having the coordinator ban Alice because Bob registered an output to her input address doesn't solve the DoS issue.


What possibilities were eliminated by the 262 input collaborators and 294 output collaborators in the WabiSabi coinjoin you linked? https://kycp.org/#/710d395ca20709096a0778927cb960a466be675b188a234b9b52ffb88bb97a3e

You claimed before that these input and output merges are "literally identifiable" but you are literally unable to identify any additional information presented at all from these merges taking place.


It says "no Boltzmann available" for WabiSabi coinjoins on kycp.org.

Personally, I combine toxic change with other toxic change where lack of privacy is minimum. I don't use it that much anymore though, because Monero is simply superior than both of you. There is an entire article on what to do with toxic changes, though: https://bitcoiner.guide/doxxic/.

It has been said multiple times already that it allows you to consolidate them with a mix partner. At this point, you're just repeating the same soundbites. WabiSabi != Whirlpool, so yeah, it doesn't allow you to consolidate just as WabiSabi does.

No. The coordinator would simply refuse to work on a coinjoin where outputs contain addresses from inputs, just as you've programmed it to refuse "naughty" coins.

Nothing is provably revealed, in the sense that I can be 100% sure to ownership identification, just as if I send all of my coins to a single address, you can't tell if it was self-transfer or I spent them to a merchant. But, privacy is about possibilities, and input / output collaborations and merges only worsen uncertainty. There is an entire analysis technique called Boltzmann score that computes resistance to this potential linking. WabiSabi coinjoin is worse in that matter, as it appears in kycp.org.

What should users do with their Whirlpool change since they can't spend it to anyone besides the specific source who originally sent them the coins in the first place?


It is Whirlpool's fault because Whirlpool doesn't allow you to consolidate your coins privately like WabiSabi enables.


Your solution would allow Bob to DoS the coinjoin coordinator by choosing an output address that matches one of the input addresses.


What information was revealed from the 262 input collaborators and 294 output collaborators in the WabiSabi coinjoin you linked? https://kycp.org/#/710d395ca20709096a0778927cb960a466be675b188a234b9b52ffb88bb97a3e

Unless the user approves linking the outputs together. Sure, generally speaking it is a bad practice, because you reveal common ownership, but if you mix regularly and receive coins from a specific source, then consolidating toxic change with other toxic change might be acceptable by the user.

The user chose to consolidate a dozen private coins into one. I agree it was a very bad practice, but it is not Whirlpool's fault.

Yes, do not allow the coordinator to accept creating outputs with the same addresses as the inputs.

Why would Bob pay another input of the coinjoin?

WabiSabi coinjoins literally have identifiable input and output merges, which I agree that they happen on multiple coinjoins that obscure the ownership, but reveal quite a lot of information. See kycp.org/#about on input / output collaborations and merges.

Whirlpool change should ABSOLUTELY NOT BE SPENT with other change because it will link both payments that created those change outputs together.  Satoshi identified this common input heuristic in the Bitcoin whitepaper:


You don't seem to understand, This user already Whirlpooled his coins and he was traced anyways:

Here's the user's Whirlpool premix transaction: https://mempool.space/tx/63679c9ec82f246811acbab0c04cc0fc77ba050e1b6c23661d78afcfc13cf8aa
Here's the Whirlpool postmix transaction where the user was tracked: https://mempool.space/tx/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db


It's not a "software problem":  Can you explain how to fix this "software problem" of an address being reused on both sides of a coinjoin?

Alice registers an input from bc1qalice
Bob registers an input from bc1qbob
Alice registers an output to bc1qanonalice
Bob registers an output to bc1qalice

Alice's address is being reused on the input side and the output side of the coinjoin.  Clearly, Alice would want to sign this coinjoin transaction if it pays both bc1qalice and bc1qanonalice since she's getting more money than she expected initially.  Can you explain how Alice receiving extra money would be a "software problem"?


WabiSabi does not share Whirlpool's problem because you can send payments directly to its destination in the WabiSabi coinjoin itself without revealing multiple inputs belong to the same wallet.


Yes, I already educated you how kycp has identified the remixing that WabiSabi users participate that massively increases their privacy:

And it is the user's fault to consolidate badbank change with private coins. Change should be spent with other change, and not with private coins, which is the reason why Sparrow doesn't even allow you to mess that up, unless you deliberately combine them in a separate transaction.

It is very avoidable. You simply choose to never combine change and private coins in one transaction.

The Whirlpool user can gather change, and once the amount is sufficient, send them over to Whirlpool.

Good, so we agree. The problem with Wasabi 1.0 was that it reused addresses in both sides, which is 100% a software problem. The problem with WabiSabi coinjoins is the same as with consolidating Whirlpool private coins without a mix partner; input / output merges, which possibly belong to the same wallet. WabiSabi coinjoins contain lots of them. Have you checked the kycp.org link?

They don't want to create change outputs though because the change addresses in Whirlpool are completely traceable: change can't be spent without linking your transactions together.  These 305 sat and 933 sat Whirlpool outputs are in addresses 100% deterministically linked to the original owner, whereas the 5000 and 6561 sat outputs from WabiSabi are spendable because they are completely anonymous.


Spending received coins and Whirlpool change together links those two transactions together.  This isn't a feature, it's an unavoidable privacy leak.


So you think the Whirlpool user should consolidate their postmix outputs within a WabiSabi coinjoin to add mix partners?  Makes sense.


If a user chooses to reuse a receive address for multiple payments, that's a conscious choice, not a problem with the software. For example, this Whirlpool user combined his traceable premix change output with his postmix outputs that were sent to a reused address:

Whirlpool premix transaction: https://mempool.space/tx/f7e015cc5f84517e45c107e3c8385b49f6f5a1196ef87fe84f495754272387f5
Whirlpool traceable change address: bc1q86n54k0f6gadrkhdsdut9r6ej3d8j68udrxggs
Whirlpool postmix outputs in reused address merged with traceable change: https://mempool.space/tx/983c459268435613fa8a19eebb7d80afae76f684ca5a2481877b37a41aab5e5a

You have already received your reply. Users are free to mess with their privacy and money. The client should not recommend them to do so, but if they nonetheless want to create dust outputs, they are free to do so. In the given transaction, it is clear that this was a conscious choice made by the user.

... yes? That's because spending your received coins and change together is generally considered a feature?

You showed proof of a Whirlpool user consolidating the many post-mix outputs into one, which agrees with my initial statement that the user is free to mess up with their privacy. If you use Whirlpool in Sparrow wallet, trying to consolidating all these will warn you that it will appear as a self-transfer, and instead will suggest you into adding a mix partner.

I don't think there's a problem with the user consciously deciding to harm their privacy and pocket. I think the problem lies with software that harms the user's privacy without them knowing.

What do you think of the dust problem in Whirlpool that wastes money for even smaller outputs?  https://web.archive.org/web/20231025112756/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/461



Using a different derivation path for the change output didn't stop those Whirlpool addresses from being linked together.

Furthermore, I showed the proof of how I linked postmix Whirlpool outputs to the premix transaction that generated it, which no one ever addressed at all:



Okay, since you seem to think there's a problem, what is the solution to the problem you are describing?  How should the coinjoin protocol be changed?

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

Setting up a coordinator doesn't cost any BTC, a coordinator just sends messages back and forth to coinjoin participants.


How would you be able to see where every tx came from or where they went?  Did you read gmaxwell's explanation about Chaumian blind signatures?

Should read:

ANYONE can run a Whirlpool coordinator, and they CAN perform a targeted attack where they only choose you to mix in rounds with 4 (or more) decoys so you gain a false sense of privacy.  Or, they could just rug pull you by not mixing your funds after you pay the coordinator fee.

There are probably more then a few people on this board sitting with 50+BTC from the early days who could setup a coordinator



Once again, if I setup a CoinJoin Coordinator for Wasabi users with a bit of tweaking it's not impossible. Getting people to use it would be the issue. But if I am charging no fees I can see where every TX came from and where they went.

---

The right tool for the right job. Hammering together something to make your BTC private will always have flaws / vulnerabilities.
It was not made to be private. Same way a VW Bug was not made to haul lumber. You can do it but why. Rent a pickup truck or a van.
Same here, want more private BTC there are enough BTC -> XRM or other privacy coins -> BTC and done.

---

Not kicking any of the people working hard to do this, but it really seems to be more effort then it's worth.

-Dave

No one sells coins to "mixers": A "mixer" is someone who gets others to deposit coins into their wallet by telling them they will keep their data secret.  Eventually, the "mixer" takes all the coins from the depositers and turns their data over to the government.  We've seen this happen many times before on Bitcointalk:

Jambler is not a mixer. It buys coins from exchanges, miners etc. and sells them to real mixers.

Nope, these descriptions are agnostic of the wallet implementation.  There's multiple wallets that use each of the coinjoin methods I listed above, I'm not getting specific.


What do you mean "as if they even mean something substantial"?  These Whirlpool addresses are linked to each other.


I clicked on the link in your signature, it says "Jambler.io mixing platform".  Did you know this is custodial?


I believe the functionality you're describing is "GroupHug" - https://peachbitcoin.com/blog/group-hug/index.html

However, as the article mentions, this does not provide privacy like WabiSabi and Whirlpool do.  gmaxwell explains the difference here:


Takers in JoinMarket are the coordinator of their own coinjoin, so their threat is reversed (e.g. Feds running multiple maker identities to spy).

Privacy with WabiSabi is guaranteed by your client, it doesn't matter if the coordinator you connect to is a Fed or not because you do not reveal UTXO links to the coordinator or trust them with any data.  

If a Fed was running a Whirlpool coordinator, they could perform a targeted attack where they only choose you to mix in rounds with 4 decoys so you gain a false sense of privacy.  Or, they could just rug pull you by not mixing your funds after you pay the coordinator fee.

There are no more mixer services here, stop trying to die on that hill. Or maybe you forgot to teleport your account to Altcoinstalks?

More on topic:


If there is a service coordinating payjoins between different wallets, which is ultimately what all of these methods boil down to, whose going to be interested in collecting the UTXO history of all the people who participate? Same with CoinJoins and coordinators. Let's say the Fed was running a coordinator, and recorded every UTXO going inside it. Where's the privacy now?

Look. I agree you believe you educate people about Bitcoin privacy, but we have repeated this conversation around solutions for privacy quite a lot of times. The fact that you still quote these whirlpool messages, as if they even mean something substantial, shows with what tenacity you're trying to sabotage Samourai. I agree with Poker Player that the more you talk, the more you ruin Wasabi's reputation.

Quite literally not. There are far more important things in this world.

Except that in your last 13 feedback of your Trust summary, people have accused you of being a horrible human being, regardless. People with no relations with mixers wrote these. Even Poker Player, who carries a Wasabi signature, and could have been considered in disadvantageous position. You cannot keep wandering around with that soundbite. Nobody buys it.

Acknowledging that everyone is going to die versus wishing and praising for someone's death are two separate things. I'm quite struggling to think what else there is to say.

I somewhat agree. People will just assume you shill Wasabi.

---

Have you checked WabiSabi paper from https://github.com/zkSNACKs/WabiSabi/releases/latest/download/WabiSabi.pdf and read section 7?


To be specific, what do you think about sentences i quoted above?

I'm educating people about Bitcoin privacy, just like I always have.  Anonymous money is quite literally the most important thing in the entire world, don't you agree?


Lol, you didn't fall for that did you?  The scammers who promote custodial "Mixer Sites" formed a mob to leave false accusations against anyone who tells the truth that Bitcoin is untraceable.


Everyone is going to die, why do you think that fact means we shouldn't have rationale debates?


The truth about Bitcoin privacy has always inspired hate because the promoters of "Mixing Site" scams don't want their source of income cut off.

Look man, I don't know what you're trying to do here. Don't you have enough with 15 neutral color tags but basically saying you're a piece of shit? Now you want to open a rational debate by quoting someone who is going to die? If it's because Wasabi pays you to represent them on the forum, the best thing you can do is stop doing it. Otherwise you're just going to inspire more hate.

- Public payments made private?
See https://bitcoin.org/en/bitcoin-paper

Transactions on the Bitcoin blockchain have infamously bad privacy. Every historical transfer of coins is recorded publicly and permanently, providing a link between the public keys used as inputs and outputs. Satoshi noted this in section 10 of the whitepaper titled “Privacy”:


- Whirlpool Coinjoins
See https://bitcoinmagazine.com/technical/how-bitcoin-anonymity-sets-work

Whirlpool is a centrally coordinated coinjoin that implements the ZeroLink coinjoin protocol with a privacy restriction that limits the anonymity you can gain. This restriction is called “tx0”, it is a self spend transaction prior to the coinjoin that allows the trusted coordinator to custody the fee they charge in order to prevent DoS attacks from being costless. Once the coordinator’s fee is confirmed, they allow the outputs created from the premix tx0 to be added to their liquidity pools. There are 4 different liquidity pools with fixed output values:

0.5 BTC
0.05 BTC
0.01 BTC
0.001 BTC

The coordinator then chooses between 5 and 8 participants for a coinjoin round who use blind signatures to create an equal sized output whose origin input is anonymous to all parties. In order to incentivize liquidity, these participants are composed of new entrants (takers of liquidity) and remixers (makers of liquidity). The mining fee for the block space used by remixers is paid for by the new entrants, so the value a user receives from their first round does not change after they are selected to remix in future rounds.

- Can Whirlpool be traced?

Yes, the common input ownership heuristic and change output heuristics are revealed by the premix tx0, creating a 100% link between a Whirlpool user’s addresses. Any UTXO that does not precisely add up to a multiple of 0.5, 0.05, 0.01, or 0.001 (+fees) cannot gain complete privacy. There are no advanced calculations required to determine these links between addresses, they are visible to the naked eye:


Postmix transactions can be traced to premix funds when outputs from child rounds of the same premix transaction are consolidated. Consolidation of mixed outputs from the initial round may be unavoidable since users do not have control over whether or not they remix: