Can Coinjoin transactions be traced? Busting Bitcoin privacy myths! - page 2.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

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.

Quote

Something that can never be understated is that Bitcoin's privacy assurances are extremely subpar at the moment. It is possible to transact privately, but it is extremely hard. CoinJoins help a bit, but must be approached tactically. One must consider where their soon-to-be-mixed UTXOs came from, how many UTXOs they are mixing at once using the same service, how many other individuals they are mixing with, where they send the UTXOs post-mix, how they deal with change after spending mixed UTXOs, and co-mingling post-mix UTXOs just to name a few variables. I could go on much longer. The only way to figure out how to do this correctly is to study.

https://tftc.io/issue-599-coinjoin-ergobtc/

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

riqo

newbie

Activity: 27

Merit: 8

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

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: Kruw on February 11, 2024, 07:27:38 AM

Quote from: satscraper on February 09, 2024, 07:43:15 AM

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

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

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: satscraper on February 09, 2024, 07:43:15 AM

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.

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

Quote from: satscraper on February 09, 2024, 07:43:15 AM

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,

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:

Quote from: arstechia

Satoshi had hinted at the privacy dangers this introduced. “Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner,” Satoshi wrote. “The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.”

So, as Meiklejohn’s first step, she simply tried the technique Satoshi had inadvertently suggested—across every bitcoin payment ever carried out

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.

satscraper

hero member

Activity: 714

Merit: 1298

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,

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 01:45:47 PM

Avoiding my point, as usual.

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:

Quote from: Kruw on February 01, 2024, 10:38:59 AM

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

Personally, I combine toxic change with other toxic change where lack of privacy is minimum.

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

Quote from: Kruw on February 01, 2024, 12:02:33 PM

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

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

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?

Quote from: BlackHatCoiner on February 01, 2024, 01:45:47 PM

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

Quote from: o_e_l_e_o on November 07, 2023, 10:39:52 AM

2 - Tx0 clearly pays the coordinator, and this output is easily identified. The privacy of Whirlpool coinjoins does not depend on this fee payment being secret. It does not matter if you and I both pay to the same coordinator address - there is zero loss of privacy.

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

Quote from: BlackHatCoiner on February 01, 2024, 01:45:47 PM

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.

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 01:12:59 PM

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

Avoiding my point, as usual.

Quote from: Kruw on February 01, 2024, 01:12:59 PM

The only address that a user does not have a choice whether or not they reuse is the address they pay the coordinator fee to. The bug report submitted to the Whirlpool coordinator detailing the reuse of their receive addresses was deleted without any comment: https://web.archive.org/web/20231025112815/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/462

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

Quote from: Kruw on February 01, 2024, 01:12:59 PM

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

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 12:50:04 PM

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

Quote from: BlackHatCoiner on February 01, 2024, 12:50:04 PM

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.

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

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 12:02:33 PM

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

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.

Quote from: Kruw on February 01, 2024, 12:02:33 PM

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?

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

Repeated soundbite. I ignore.

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.

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

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

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?

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

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.

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.

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

I said:

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

WabiSabi coinjoins literally have identifiable input and output merges

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.

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?

Quote from: BlackHatCoiner on February 01, 2024, 11:21:05 AM

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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

Repeated soundbite. I ignore.

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

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

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

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.

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

I said:

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

WabiSabi coinjoins literally have identifiable input and output merges

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.

Quote from: Kruw on February 01, 2024, 10:38:59 AM

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

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

Personally, I combine toxic change with other toxic change where lack of privacy is minimum.

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

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

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.

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

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

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.

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

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

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.

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.

Quote from: BlackHatCoiner on February 01, 2024, 10:03:28 AM

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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 08:57:40 AM

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?

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

Quote from: Kruw on February 01, 2024, 08:57:40 AM

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

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.

Quote from: Kruw on February 01, 2024, 08:57:40 AM

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

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.

Quote from: Kruw on February 01, 2024, 08:57:40 AM

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

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

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.

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?

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

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.

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

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

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?

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

Quote from: BlackHatCoiner on February 01, 2024, 08:28:49 AM

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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 08:05:10 AM

Whirlpool change should ABSOLUTELY NOT BE SPENT with other change because it will link both payments that created those change outputs together.

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.

Quote from: Kruw on February 01, 2024, 08:05:10 AM

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

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.

Quote from: Kruw on February 01, 2024, 08:05:10 AM

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?

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

Quote from: Kruw on February 01, 2024, 08:05:10 AM

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

Why would Bob pay another input of the coinjoin?

Quote from: Kruw on February 01, 2024, 08:05:10 AM

WabiSabi does not share Whirlpool's problem of revealing input consolidation in payments because you can send payments directly to its destination in the coinjoin itself.

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 07:18:46 AM

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.

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:

Quote from: BlackHatCoiner on February 01, 2024, 07:18:46 AM

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

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

Quote from: BlackHatCoiner on February 01, 2024, 07:18:46 AM

Good, so we agree. The problem with Wasabi 1.0 was that it reused addresses in both sides, which is 100% a software problem.

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"?

Quote from: BlackHatCoiner on February 01, 2024, 07:18:46 AM

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

Quote from: BlackHatCoiner on February 01, 2024, 07:18:46 AM

WabiSabi coinjoins contain lots of them. Have you checked the kycp.org link?

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

Quote from: Kruw on October 12, 2023, 07:23:48 AM

Quote from: BlackHatCoiner on October 12, 2023, 07:12:30 AM

Quote from: Kruw on October 11, 2023, 05:04:54 PM

Where's the flaw? All those outputs are private.

There are 262 input and 294 output collaborators

That's called "remixing", those 262 inputs and 294 outputs gained even more privacy by participating in multiple coinjoin transactions. It's not a flaw, it's an advantage, because someone trying to track the flow of someone's coins now have to consider inputs from previous transactions and spends from future transactions.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on February 01, 2024, 06:13:38 AM

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.

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.

Quote from: Kruw on February 01, 2024, 06:13:38 AM

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

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

Quote from: Kruw on February 01, 2024, 06:13:38 AM

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

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

Quote from: Kruw on February 01, 2024, 06:13:38 AM

If a user chooses to reuse a receive address for multiple payments, that's a conscious choice, not a problem with the software.

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?

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on February 01, 2024, 04:30:39 AM

Quote from: Kruw on January 31, 2024, 05:28:29 PM

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

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.

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.

Quote from: BlackHatCoiner on February 01, 2024, 04:30:39 AM

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

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

Quote from: BlackHatCoiner on February 01, 2024, 04:30:39 AM

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.

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

Quote from: BlackHatCoiner on February 01, 2024, 04:30:39 AM

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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: Kruw on January 31, 2024, 05:28:29 PM

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

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.

Quote from: Kruw on January 31, 2024, 05:28:29 PM

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

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

Quote from: Kruw on January 31, 2024, 05:28:29 PM

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

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.

Quote from: Kruw on January 31, 2024, 05:28:29 PM

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?

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.

Kruw

member

Activity: 378

Merit: 93

Enable v2transport=1 and mempoolfullrbf=1

Quote from: BlackHatCoiner on January 31, 2024, 04:48:16 PM

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.

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

Quote from: Kruw on November 10, 2023, 06:57:14 AM

Tell me why anyone would ever lose their sats deliberately by creating these traceable Whirlpool dust outputs:

https://mempool.space/address/bc1qp25y8kfywz88myuh7ed3dmx3vv2z2dwuxhjnlv

Value of output: 305 sats
Mining fee paid to create output: 369 sats
Mining fee paid to spend input: 1,776 sats
Net loss from dust bug: 1,840 sats
New transactions clustered: 5 txs

https://mempool.space/address/bc1q83sfgfefwupz8w3faawxjr5v8uf03ttjclrkda

Value of output: 933 sats
Mining fee paid to create output: 1,234 sats
Mining fee paid to spend input: 4,333 sats
Net loss from dust bug: 4,634 sats
New transactions clustered: 12 txs

Quote from: BlackHatCoiner on January 31, 2024, 04:48:16 PM

I'm good at quoting old posts as well:

Quote from: o_e_l_e_o on November 10, 2023, 02:52:30 AM

As has been explained to Kruw dozens of times, the change output from Tx0s are sent to a separate account and deliberately segregated from your other UTXOs. There is no way to accidentally include them in a transaction. Any user consolidating their change output as has been done in the transaction he has linked to above is doing so deliberately. I understand that Kruw gets angry when people spend their bitcoin in ways that he personally doesn't approve of, but there is no bug here, just Kruw either being deliberately misleading or simply not understanding what is happening.

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:

Quote from: Kruw on September 30, 2023, 11:59:57 AM

Quote from: o_e_l_e_o on September 30, 2023, 08:28:20 AM

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

Quote from: BlackHatCoiner on January 31, 2024, 04:48:16 PM

Quote from: Kruw on January 31, 2024, 03:57:22 PM

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

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

Quote from: Kruw on November 09, 2023, 02:09:37 PM

I guess I can't argue against someone who takes the stance "Wasting your Bitcoin and ruining your privacy should be allowed."

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

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?

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