Pages:
Author

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

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Question for experienced JoinMarket users: How frequently do you participate in a remix as a maker?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
LaurentMT confirms that Whirlpool's incentive model was designed to provide the least amount of anonymity possible: https://twitter.com/LaurentMT/status/1783589807668535563
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.

Some Whirlpool users were rugpulled because they paid coordinator fees in a separate transaction from their coinjoin: https://mempool.space/address/bc1q6dxnvx3wm40e4rtmye6fwy9zmwnqchnz04pzaa
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1

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.

Mempool.space seems to have applied the "Coinjoin" tag to this Whirlpool tx0 transaction as well: https://mempool.space/tx/97a6b985f48c2faf4a3cb7c1e4b5a0ac230fd59aac33723101de9dd144bd735e
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.

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
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Is everyone still fighting over which CoinJoin is the best in Bitcoin Land?

Coinjoining takes time and block space, and since both are limited resources, the debate is consequential. No one wants to waste either.
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.
newbie
Activity: 27
Merit: 8
I gave you some merit because at least you are trying smh
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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:

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

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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:

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?

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?

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

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

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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.

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.

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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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:

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

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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.

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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.

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?

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.

I said:
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?

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
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.

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.

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.

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

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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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?

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.

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.

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.

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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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/.

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.

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.

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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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?

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.

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.

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
Pages:
Jump to: