Can Coinjoin transactions be traced? Busting Bitcoin privacy myths!

[Kruw]

- 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”:

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.

Consolidating inputs indicates common ownership when you spend your coins alone, but it’s not necessarily revealing since a multiparty transaction can be constructed containing inputs (and outputs) from others. This type of transaction is called a “Coinjoin”.

Different types of coinjoins provide different privacy guarantees, but they are all inherently non custodial. Various specifications and protocols have been designed to facilitate coinjoins depending on the scenario. Please note that these descriptions target the protocol level, wallet level implementation details are not applicable to these explanations:

- Payjoin
See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021868.html

A payjoin is a coinjoin that a sender and recipient construct together. This provides marginal privacy gains to each participant by combining their histories while also saving on the receiver’s future cost of block space. Since an output is already being created for the merchant receiving funds, the receiver can opportunistically consolidate their inputs at the same time. A notable advantage of payjoins is that they blend in with regular on chain transactions, as opposed to equal output coinjoins which have a distinct footprint. Another advantage is that the value of the payment is obscured since neither output created matches the amount of value transferred between participants.

In the context of Lightning, this two party interaction is known as “Dual Funding”, where two peers can open a payment channel using inputs from each user. Additionally, new funds can be “spliced in” to the channel without indicating which peer consolidated the input. On chain payments can be “spliced out” that could have been sent by either channel participant while leaving the channel open as the change output.

- Can payjoins be traced?

Not from the outside. However, the disadvantage of payjoins compared to other coinjoins is that the sender and receiver are completely aware of the coins owned by the other participant, which introduces a trusted single point of failure. In theory, a payjoin could be composed with inputs from more than two parties, however, this introduces a time element since some parties must pause their transaction and wait for others to join instead of paying instantaneously.

- JoinMarket Coinjoins
See https://nixbitcoin.org/orderbook/

JoinMarket is a peer to peer marketplace for coordinating coinjoins using “Makers” and “Takers”. Instead of a payjoin where the sender collaborates directly with the recipient who provides their own liquidity, senders using JoinMarket collaborate with anonymous strangers on the marketplace and buy their liquidity.

The privacy of JoinMarket coinjoins is produced by having each peer create an output of equal value, making it unattributable to their originating inputs. There is a minimum of 0.00027300 BTC required to participate, and no maximum. JoinMarket is the most flexible coinjoin protocol since private payments can be made on demand by takers, and privacy can be gained passively on the coins sitting in the wallets of makers.

- Can JoinMarket be traced?

Not as a taker. Since takers choose the equal value output size, they can make coins from incoming payments anonymous or anonymize their change at any time without trusting anyone. Fidelity bonds help protect takers against makers performing Sybil attacks.

However, makers trust their information with the taker of any individual transaction, the coinjoin only provides privacy from outside observers. Makers generally only gain privacy on the equal value output, producing change. Makers reveal the ownership of their UTXOs to takers who propose an offer, but ring signatures are used to help protect makers from revealing their funds to malicious takers that do not complete the offer.

- WabiSabi Coinjoins
See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020202.html

WabiSabi is a centrally coordinated coinjoin protocol that utilizes keyed verified anonymous credentials and a timed round for gathering liquidity. Each user can register multiple inputs directly to the coinjoin transaction anonymously without indicating common ownership, and change outputs are not created (if there is sufficient liquidity). This model allows a “smart client” to choose matching output amounts based on the input amounts registered in the start of the round instead of having the coordinator dictate the values allowed to “dumb clients”.

The advantage of WabiSabi is that the coinjoin structure completely eliminates the links between your addresses when sending or receiving transactions without needing to pay attention to the labels or values of your inputs. WabiSabi is highly block space efficient since input consolidation, mixing, and payment batching can all be performed in the same transaction without premixing or postmixing.

- Can WabiSabi be traced?

Not unless you are the biggest whale in a coinjoin round with insufficient liquidity. Even outputs that do not have matching amounts cannot be traced to an owner on the input side - it’s even possible that the output changed hands as a payment to someone who did not own any funds on the input side at all:

you don't need to be a "whale" at all in order to receive absolutely zero privacy from a Wasabi coinjoin.

Okay then, I'll call your bluff again- Here's 20 non whale non matching outputs from WabiSabi coinjoins, try to identify the inputs owned by even a single one of the 20 outputs (which would be 5%):

01 bc1q032caguldmlrrztmrwhv5wqveyywdu2rtmd740
02 bc1q6vgwhsfkg343mmh27vc6prg3clsd4xu3p68vyd
03 bc1qre8jjpu8p9taw8j44r39z56vfr4sw64d4wyaj4
04 bc1qarharg76gfcrvskfw46f67vtqzd6hxa9pnspp5
05 bc1q4sexgt2p96x3ytnjjttp59w6mkj00kedal3xze
06 bc1qwrf50wpjws5mhdg2rhdu5hy7nqdtl8z94lp75n
07 bc1qz0tal2udfpr20x793fdw6v8lzp2qze7z5zje64
08 bc1qqw2h7fa3n8vyxgqru664fmft2trl9sqh9kz3fp
09 bc1qsud748whmum4gpt2qu52z8gqlgzcjyvhd5w2a5
10 bc1qctvxddyvxupjj8w82m8w5grzn59arstlrnaauw
11 bc1qq2fl05cmmhkr3pzg8elyr859v2fpcltynrk2j5
12 bc1qvwkrd3aecrvql5j8mqkmketvw6g6qwzt4juprq
13 bc1qhc2565fac4lrgyfq6n0mzc0l86jeptfnv2um9x
14 bc1qat6445gutyl3qdz3zhmdng9cdt92mevjlvaljs
15 bc1qk5f3mz0fetccey4nyyjedlrmqstkz2hmun96ha
16 bc1q4tpvm378a9d4n0xcnjtwfwujtr8eatjzvru8dx
17 bc1qd5epyjpj6vuejdppj24wew5n4n5rzepjx2xnay
18 bc1qgafud63me5mffn00g90ch08jjn5h20umzwxd62
19 bc1q5u3f2ldrtqa7ea79a8hcd8kssgw2gmalk4uej9
20 bc1qa6n7g7r4j3nv78gzgzmuvg56em4guppckqpz7r

- 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:

Post the tx ID of any Whirlpool transaction and I will show you the tx0 transaction that was created by each of the new entrants.

Ok, here's one: https://mempool.space/tx/ed3131b544fbf00a71709942e483b55e629312ecb181e6e819409f419ee0d226

Where exactly is the privacy loss for new entrants, splitting a single UTXO in to multiple UTXOs to join the pool?

Okay, here's all the payments that can be tracked from the two new participants of the Whirlpool coinjoin transaction:

Entrant 1: bc1q03c0443ausjjdxl2h6ud5m8c0dux0zyg3dqdj7 created 0.00170417 BTC in unmixed change sent to bc1q3fduld0l3r8nclyt5p3r7ak675tekurstn55tl.  Since this UTXO is not private, the sats were marked as unspendable and have not been recovered by the wallet owner  

Entrant 2: bc1qzc8zku26ej337huw5dlt390cy2r9kgnq7dhtys created 0.00191247 BTC in unmixed change sent to bc1qjlltxr443uy236wl4xhpxlr6dgsu0zltlv3m44. This UTXO was used in a second tx0 transaction, creating a huge trail of transactions that could be traced to each other  

The 2nd tx0 transaction created 0.00076348 BTC unmixed change which was sent to bc1qehd7gy8rza9mnzm9wnfjhgw82rp47wmqt7vpgy

Since this unmixed change is below the .001 pool minimum, it was consolidated in a 3rd tx0 with 3 other addresses owned by the same wallet:
31x8GPqrhzdaxiBJa9N5UisuoxbX1rAnHa
16Gw5WKjbxZmg1zhZQs19Sf61fbV2xGujx
3LZtsJfUjiV5EZkkG1fwGEpTe2QEa7CNeY

The 3rd tx0 transaction created .00200317 in unmixed change which was sent to bc1q2p7gdtyahct8rdjs2khwf0sffl64qe896ya2y5
This was spent in a 0.00190000 payment to 3B8cRYc3W5jHeS3pkepwDePUmePBoEwyp1 (a reused address)

That payment left .00008553 in change that was tracked to 3Dh7R7xoKMVfLCcAtVDyhJ66se82twyZSn and consolidated with two other inputs in a 4th tx0 transaction:
bc1qeuh6sds8exm54yscrupdk03jxphw8qwzdtxgde
3ByChGBFshzGUE5oip8YYVEZDaCP2bcBmZ

This 4th tx0 created .00533406 in unmixed change which was sent to bc1qzh699s75smwukg9jcanwnlkmkn38r79ataagd9 which was consolidated with 3 more addresses into a 5th tx0:
3F2qiWQJKQjF7XFjEo8FUYP3AU5AC6RqX8
3HAYYVKUpYbr2ARMdZJr9yVu8xi8UcxtPz
3GQtwwRK31wwCc22q6WS5sCgixUHsG5KaT

The 5th tx0 created 0.00058494 BTC in unmixed change that was sent to bc1qvh2zjcwwkj9y70xulla2semvlav3lty0p3l3w3
This was spent in a .00047290 payment to bc1qvzg8jq6wqtr5navn4e3ps4qrkk9r6n4h98gjck

That payment left .00008411 in change that was tracked to bc1qg6j0f0wfhpktt2l8uzdn48ct3um2xyur40eyzd and consolidated with another input into a 6th tx0 transaction:
31iZLXWfoywhuMZTPGxTkpzphzh2NXshpP

The 6th tx0 created .00753775 in unmixed change that was tracked to bc1qgfll2apc27yct6h2c8r8wq4kqhxjsfrudhhn5q
This was spent in a .00737000 payment to bc1q5emzer2t0sq5dez0zsrqgh6scvwn0n24xsladp (a reused address)

This payment left 0.00010896 BTC in change which has not been spent yet, but the payment only took place 11 days ago, so I assume it will eventually be spent, allowing the Whirlpool user to be tracked even further.

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:

The first is the fee to Whirlpool itself, which is a flat fee depending on the pool you are joining.

The flat pool entry fee structure is designed to incentivize worst privacy practices.  Since fees are not collected directly based on volume, it is cheaper to participate in a smaller pool and create more outputs than participate in a larger pool and create less outputs. Additionally, it incentivizes revealing common inputs ownership of premix UTXOs since it is cheaper to consolidate them to enter the pool once than to enter the pool with each UTXO individually.  Samourai has never explained why they purposely chose a fee structure that heavily penalizes the most private usage of their protocol.

Because of this backwards design, you can easily link premix inputs to postmix outputs in many cases.  Notice how this Whirlpool tx0 premix creates 70 outputs for 0.05 BTC - https://mempool.space/tx/63679c9ec82f246811acbab0c04cc0fc77ba050e1b6c23661d78afcfc13cf8aa

Notice how every single input of this Whirlpool exit transaction is a direct descendant of rounds created by the aforementioned premix transaction: https://mempool.space/tx/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db

When many inputs used in the postmix exit transaction are created directly from a round that the premix transaction entered, it makes it trivial to trace the user through Whirlpool.  Fortunately, the user abandoned Whirlpool and upgraded to using the WabiSabi coinjoin protocol instead, which made him completely untraceable: https://mempool.space/address/bc1qjjw5gaglkycu2lm5fskl7qhktk0hec4a5me3da

[1714707399]

1714707399

[Poker Player]

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.

[Kruw]

Look man, I don't know what you're trying to do here.

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?

Don't you have enough with 15 neutral color tags but basically saying you're a piece of shit?

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.

Now you want to open a rational debate by quoting someone who is going to die?

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

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.

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.

[ABCbits]

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.

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

- Can WabiSabi be traced?

Not unless you are the biggest whale in a coinjoin round with insufficient liquidity. Even outputs that do not have matching amounts cannot be traced to an owner on the input side - it’s even possible that the output changed hands as a payment to someone who did not own any funds on the input side at all:

--snip--

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

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

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

[BlackHatCoiner]

I'm educating people about Bitcoin privacy, just like I always have.

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.

Anonymous money is quite literally the most important thing in the entire world, don't you agree?

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

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.

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.

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

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.

[NotATether]

Don't you have enough with 15 neutral color tags but basically saying you're a piece of shit?

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.

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:

- Can payjoins be traced?

Not from the outside. However, the disadvantage of payjoins compared to other coinjoins is that the sender and receiver are completely aware of the coins owned by the other participant, which introduces a trusted single point of failure. In theory, a payjoin could be composed with inputs from more than two parties, however, this introduces a time element since some parties must pause their transaction and wait for others to join instead of paying instantaneously.

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?

[Kruw]

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

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.

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts.

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with.  Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay.

Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

Clients abandon rounds after multiple successive failures as a basic way to prevent this.

_____________________________

I know you didn't mention it, but I disagree with this conclusion in section 7 of the WabiSabi paper:

Denial of service is not costless because unspent transaction outputs are a limited resource.

This is incomplete because the marginal cost of a DoS attack is zero if you are going to spend your UTXO anyways.

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.

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

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

I clicked on the link in your signature, it says "[banned mixer] mixing platform".  Did you know this is custodial?

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?

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:

Don't the users learn which inputs match up to which outputs?

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

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?

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.

[NotATether]

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

I clicked on the link in your signature, it says "[banned mixer] mixing platform".  Did you know this is custodial?

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

[Kruw]

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

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:

Destroying the session deletes chip private key.

Even my chips which I had in chipmixer service for which they claimed to "delete private" keys after 7 days or whatever, were seized/transfered. and these transactions took place good 3 months ago.

It seems that you are right, whoever had vouchers or chips was left without them. I checked some old wallets older than 1 year that only contained chips from CM, and they were all emptied. Yes, it's a bit stupid that I didn't spend them, but honestly I forgot about a few $ in those old wallets. It's really strange that it wasn't all deleted, but now we at least know where even 7GB of data came from.

Can confirm, they stole a chip of mine a friend of mine that he hadn't yet spent. :/ Really fucking bad practice of ChipMixer to keep private keys, not gonna lie.
It was still there today morning and even when the news broke here; I he had not considered that private keys may have been backed up on CM servers to be honest.

I really can't believe this is an exit scam. The service seemed legitimate.

I'm really pissed off, and not because I lost money; fortunately, I had grasped that "don't leave coins to third parties" cliché. I'm so pissed off because I've been advertising and recommending this shit for months, in such a way that I'm practically part of this scam. And it's just feels awful.

It makes you question the integrity of the service you're currently carrying in your signature.

To all criminal users of former mixer Sinbad.io,
This is a collective warning issued by the Dutch Investigation Service for Financial and Tax Crime (FIOD) and the Dutch Public Prosecution Office.
Our investigation has uncovered illicit activities on this mixer platform and the logs obtained have compromised the anonymity of numerous users.
We urge all criminal users and admins of mixers to cease all unlawful actions immediately. Persistent engagement will lead to severe legal consequences. We are resolute in pursuing and prosecuting all involved in criminal activities.
Your anonymity is no longer assured. Law enforcement actions are imminent.
With Vigilance,
Dutch Investigation Service for Financial and Tax Crime (FIOD) and the Dutch Public Prosecution Office

[DaveF]

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.

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

- Can WabiSabi be traced?

Not unless you are the biggest whale in a coinjoin round with insufficient liquidity. Even outputs that do not have matching amounts cannot be traced to an owner on the input side - it’s even possible that the output changed hands as a payment to someone who did not own any funds on the input side at all:

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

[Kruw]

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

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

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.

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?

Don't the users learn which inputs match up to which outputs?

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

[DaveF]

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

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

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.

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?

Don't the users learn which inputs match up to which outputs?

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

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

[Kruw]

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

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

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.

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?

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

Ordinals has absolutely nothing to do with coinjoins.

[DaveF]

Ordinals has absolutely nothing to do with coinjoins.

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

[Kruw]

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

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

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.

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.

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 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.

[decodx]

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.

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.

[Kruw]

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.

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

[ABCbits]

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts.

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with.  Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay.

Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

Clients abandon rounds after multiple successive failures as a basic way to prevent this.

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.

I know you didn't mention it, but I disagree with this conclusion in section 7 of the WabiSabi paper:

Denial of service is not costless because unspent transaction outputs are a limited resource.

This is incomplete because the marginal cost of a DoS attack is zero if you are going to spend your UTXO anyways.

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

[Kruw]

That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack.

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:

Don't you need tor or something to prevent everyone from learning everyone's IP?

Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)

However, gumming up "taint analysis" and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.

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.

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

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

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.

[ABCbits]

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.

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

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.