Pages:
Author

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

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Shouldn't the client give the user control over how many times it can divide an input? For example, one might not prefer to divide their 0.01 BTC into 5 worth of 200,000 sat each, because it's more expensive. And I did experience it as well, if you want some feedback; I felt as if I wouldn't know beforehand how much money would be spent on the transaction fee.

The client is only able to calculate all of the potential output decompositions after the end of the input registration phase, so it's not possible to do this manually with precision. But yes, the "slot machine" aspect can be frustrating if overpaying fees bothers you.

BTCPay Server's coinjoin plugin allows power users to choose a minimum denomination amount, exclude certain denominations, etc so they can avoid surprises.

Is there any particular reason why taproot addresses are preferred over segwit?

You're not going to like the answer, lol. It's a bug: The ratio should be ~50/50 Roll Eyes

If you find the source of the bug in the code and open an issue accurately describing it, I'll award a 50k sat bounty. If you open a PR that fixes it and gets merged, I'll award a 100k sat bounty.

Isn't it less block space efficient?

Taproot is barely less efficient than segwitv0 when measured in vbytes, but it's much more efficient in terms of actual bytes. If the witness discount multiplier were slightly lower than 4, then Taproot would win out in both categories.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
These small standard outputs aren't "change", but they are treated like change by the client due to a lack of other matches. Despite being assigned a weak score, these outputs are completely impossible to attribute to any specific input in practice.
I see. You just don't assign them a metric, because that'd be against the notion of being as rigorous as possible with defining the anonymity score.

Quote
I received 5 same sized outputs from a single round, so the client divided the anon score gain of each of those outputs by 5. While this seems like "waste" from the calculator's perspective, the real world effective privacy gains of allowing this sort of amount skew is massive since analysts have to consider many subsets of possible compositions and decompositions.
Shouldn't the client give the user control over how many times it can divide an input? For example, one might not prefer to divide their 0.01 BTC into 5 worth of 200,000 sat each, because it's more expensive. And I did experience it as well, if you want some feedback; I felt as if I wouldn't know beforehand how much money would be spent on the transaction fee.



Is there any particular reason why taproot addresses are preferred over segwit? Isn't it less block space efficient?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Here's a couple of anecdotal transactions showing some nuances of anonymity score.

In this smaller coinjoin transaction, there were (at least) 4 different standard denominations that received anonymity score 1.

bc1pn5g6wmqs2prld00g5sp4l6837s6xt0lg27smt0zrgdlca9qdkycs3ernz8 - ‎0.00020000 BTC    
bc1pjvng7exw3d6ttu438249yasrpuprfwgc8mz6a55thxmat9hm08csgv6s0v - 0.00016384 BTC    
bc1phwkkwk6n2l75xg64wp3nsevkawzhgc9kpfs3rg99a5cghqw7mssq527s9v - 0.00013122 BTC    

These small standard outputs aren't "change", but they are treated like change by the client due to a lack of other matches. Despite being assigned a weak score, these outputs are completely impossible to attribute to any specific input in practice.

bc1qm2kmhgde2fey05ef2dhj3s35a9ayduke2uhgsu 2.68435456 BTC

Although the largest output appears like a whale created a change output, this amount is actually a standard denomination. The user who received this output was unlucky that the other whales in the transaction randomly allocated their liquidity to 2.00000000 BTC sized outputs instead. Even though this output received anon score 1, it's still difficult to determine which input is responsible for creating this coin (although it's far easier to guess who created an output worth 2.68435456 BTC compared to an output worth 20000, 16384, or 13122 sats).

___________________

Here's another rare anon score outcome I personally experienced -



I received 5 same sized outputs from a single round, so the client divided the anon score gain of each of those outputs by 5. While this seems like "waste" from the calculator's perspective, the real world effective privacy gains of allowing this sort of amount skew is massive since analysts are forced to consider many subsets of possible compositions and decompositions.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
So, what should normally happen? Some other participant creates an output of the same value as mine?

It often requires creating 5 to 6 outputs to efficiently decompose into matching values with other users. Creating less than 3 outputs is a pretty rare outcome.

I thought that output values follow this denomination standard.

Clients automatically filter some potential denominations depending on the inputs present in the round. Here are all of the possible standard values: https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-are-the-equal-denominations-created-in-a-coinjoin-round

I suppose that if outputs have to be those values, then I will always have change in the coinjoin with score 1. (Unless edge cases where the change is exactly one denomination.) I'm just wondering: will it ever display that the privacy progress is 100%? If yes, under which circumstances? For all I understand, it should only approach it.

Clients automatically forfeit small dust amounts that can't be decomposed evenly into standard denominations. It's not a perfect solution, but it's a reality of blockchain scalability that some UTXOs aren't worth creating or spending. Similarly, I opened an issue in Samourai's repository (which the developers deleted  Cry) pointing out how their coinjoin client was forcing the creation of uneconomical dust outputs instead of allocating these sats to the mining fee for the premix transaction or the mix transactions.

Can I put an onion URI in there?

Yes, I'm not quite sure what the correct formatting is though.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Interesting. 0.01 BTC is not large enough to require creating a change output, so I guess you just got really unlucky and no one else decomposed a matching value for your second output?
So, what should normally happen? Some other participant creates an output of the same value as mine? I thought that output values follow this denomination standard. I suppose that if outputs have to be those values, then I will always have change in the coinjoin with score 1. (Unless edge cases where the change is exactly one denomination.)

Quote
You can change it back to 127.0.0.1:8333 if you want to choose random P2P nodes.
Can I put an onion URI in there?

Quote
Although anonymity score is a decent metric, I feel like there are many more properties that should be accounted for besides just the number of matched outputs.
I'm just wondering: will it ever display that the privacy progress is 100%? If yes, under which circumstances? For all I understand, it should only approach it.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
No, I don't think so. I downloaded Wasabi Wallet, latest version v2.3.0, and inserted "https://coinjoin.kruw.io/" in the coordinator URI.

Interesting. 0.01 BTC is not large enough to require creating a change output, so I guess you just got really unlucky and no one else decomposed a matching value for your second output?

By the way, my Bitcoin P2P Endpoint is "Unspecified/Unspecified/Unspecified/3:8333". I changed it with my local node, but it didn't work for some reason, and I undid it. And this is what it displays since then.

Serialization for this field was fixed and will be in the next release: https://github.com/WalletWasabi/WalletWasabi/issues/13530

You can change it back to 127.0.0.1:8333 if you want to choose random P2P nodes.

Okay, that makes sense. "Anonymity score" is a vague factor, and it should be calculated very rigorously. My question then is: why does my client allow splitting the input into two outputs if one of them won't meet the "sufficient score" if I can phrase it that way? Wouldn't it make more sense if the input created only one output?

Gaining anonymity score on part of your balance is preferable to gaining no anonymity score at all. There's two ways to implement the scenario of insufficient privacy gains before signing, depending on whether you want to save mining fees or guarantee privacy. BTCPay Server's implementation will abandon signing the final PSBT if it calculates the outcome would lead to a net loss of score (DoSing the round and waiting out a ban). However, this can leak metadata (failed common input registrations), and could create a positive feedback loop that causes all clients to fail one at a time (in theory).

Although anonymity score is a decent metric, I feel like there are many more properties that should be accounted for besides just the number of matched outputs.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
That seems like an unusual decomposition. It sounds like you were using the BTCPay Server coinjoin plugin?
No, I don't think so. I downloaded Wasabi Wallet, latest version v2.3.0, and inserted "https://coinjoin.kruw.io/" in the coordinator URI.

By the way, my Bitcoin P2P Endpoint is "Unspecified/Unspecified/Unspecified/3:8333". I changed it with my local node, but it didn't work for some reason, and I undid it. And this is what it displays since then.

Quote
Although this unique output is more difficult to track due to the coinjoin, it's unclear how to calculate the amount of privacy it gains, so the client just assumes it is zero and just remixes the coin.
Okay, that makes sense. "Anonymity score" is a vague factor, and it should be calculated very rigorously. My question then is: why does my client allow splitting the input into two outputs if one of them won't meet the "sufficient score" if I can phrase it that way? Wouldn't it make more sense if the input created only one output?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
I feel the need to apologize for my earlier statement claiming that WabiSabi coinjoins have weak privacy. Specifically, I argued that WabiSabi coinjoins have a lower Boltzmann score compared to Whirlpool. However, this assertion was both gravely inaccurate and failed to make a valid point. Calculating the Boltzmann score for a WabiSabi coinjoin is infeasible due to its large transaction size. Even if such a calculation were possible, attempting to match inputs with outputs would still amount to mere guesswork.

I also want to apologize for likely making many statements about WabiSabi without giving them proper thought or grounding. It seems I misjudged due to insufficient study on my part.

This is very humble, I appreciate you approaching the subject again.

I recently gave WabiSabi a try, and I have a question. I joined an input worth ~0.01 BTC using your coordinator, and created two outputs. One of them has an anonymity score of 21, the other has 1.

That seems like an unusual decomposition. It sounds like you were using the BTCPay Server coinjoin plugin?

How is this calculated exactly? If it's joined in the coinjoin, shouldn't it be greater than 1? Does this imply it's possible to determine that the 0.01 BTC input created that specific output with high certainty?

"Anonymity score" is a best attempt to measure the privacy gained from a coinjoin round, but it's extremely conservative in order to handle edge cases. If you got an output with a score of 21, that means that there were 20 other outputs created in that round with the same exact value. If your other coinjoin output kept a score of 1, that means it did not match the same value as any other outputs from the round. Although your unique output was made more difficult to track due to the coinjoin, it's unclear how to calculate the amount of privacy it gains, so the client just assumes it is zero and just remixes the coin. This guarantees that whales who create change will eventually break that change down into amounts that blend in evenly with the rest of the pool.

Anonymity score is also divided by the frequency of your outputs. For example, if you created 2 outputs for 0.01062882 BTC out of 22 matches with the same value, then the anonymity score you receive for each coin would be 11.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
I feel the need to apologize for my earlier statement claiming that WabiSabi coinjoins have weak privacy. Specifically, I argued that WabiSabi coinjoins have a lower Boltzmann score compared to Whirlpool. However, this assertion was both gravely inaccurate and failed to make a valid point. Calculating the Boltzmann score for a WabiSabi coinjoin is infeasible due to its large transaction size. Even if such a calculation were possible, attempting to match inputs with outputs would still amount to mere guesswork.

I also want to apologize for likely making many statements about WabiSabi without giving them proper thought or grounding. It seems I misjudged due to insufficient study on my part.



I recently gave WabiSabi a try, and I have a question. I joined an input worth ~0.01 BTC using your coordinator, and created two outputs. One of them has an anonymity score of 21, the other has 1. How is this calculated exactly? If it's joined in the coinjoin, shouldn't it be greater than 1? Does this imply it's possible to determine that the 0.01 BTC input created that specific output with high certainty?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
I have read the whole thread and it seems to me that there is no perfect solution between these options(?)

I suppose not if your standard of 'perfect' is 100% guaranteed privacy with no thinking involved. However, liquid coinjoins using the WabiSabi protocol create a practically infinite amount of results, you can attempt to trace participants yourself: https://mempool.space/tx/70aad1d92dd3fc6ddbd802ed20ed155472a5752126a0c3489b56fde6e4cf801c
?
Activity: -
Merit: -
I have read the whole thread and it seems to me that there is no perfect solution between these options(?)
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Another Bitcointalk user attempted the challenge of tracing a WabiSabi coinjoin:

wasabi2.0 is a waste of money and fee and doesn't protect users privacy

Ok, prove it then: Show me which specific outputs were created from each input of this coinjoin transaction: https://mempool.space/tx/2248a68222cb0aa591cc00b51bbf3dd13df09622cd8d0061ae6c0df48943b0a5

He failed to produce any results Roll Eyes
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
A new challenger has appeared! dkbit98 claims Bitcoin is not anonymous. However, he was unable to trace a WabiSabi coinjoin:

Bitcoin Is Not Anonymous.

Okay, prove it then. Show me which specific outputs were created from each input of this coinjoin transaction: https://mempool.space/tx/d26a197368167f7ed2e57bd7257d9d353131bd5e7a03fcc91c68828edbb2a210
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Unlike coinjoins with a fixed output size chosen by the coordinator, WabiSabi coinjoins organize output amounts optimistically from the client side. When creating huge rounds with lots inputs, it's easy for clients to match their output amounts with each other. With smaller rounds, the efficiency decreases. For this reason, the default coordinator in Wasabi Wallet requires at least 150 inputs for a round to begin, but other coordinators may require lower input minimums. For example, this WabiSabi coinjoin only has 40 inputs: https://mempool.space/tx/9709771a2dc9a1343327776a1f52e6ae75adb981cabdab449408099d5851baf2
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Whoever stood for the childish arguments Kruw had back then looks pretty silly now when you have Kruw himself running an uncensored coordinator, which is doing the exact opposite of what he said himself, which was that Censorship is the morally correct thing to do.
Oh, yes. The censorship chapter of this saga, unending. "You shouldn't coinjoin if you're a criminal" <-- they've literally said that. If you read that post, you can see Max arguing that Bitcoin is permissioned, and you can send "bad coins" only if you own hashrate or bribe a miner. And we're supposed to trust the skills of these clowns.

Oh, and since I've sent you to that post already, read my favorite part:
Quote
There’s a lot of nuance here, but in general what we can say is: yes—that is another precedent that UTXOs are not fungible, that there is metadata associated to UTXOs that are outside of the consensus implementation. And that’s just super difficult because now you’re gonna have different surveillance companies that have different blacklists and different risk scores associated to it. And now you have competing soft forked clients, basically, that reach a different consensus of which coins are good and which coins are bad. And well—there’s no solution to it.

There is no solution to which coins are good and bad, but let's buy chain analysis crap data and grant them control over who gets to coinjoin and who doesn't.  Grin
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
At this point, any body who reads a discussion in which Kruw has participated and decides Kruw is to be trusted deserves the future consequences of their own stupidity.

You don't have to trust me.

We both know Wasabi is NOT to be trusted and I would definitely have many other options over it.

You don't have to trust Wasabi. It's trustless open source software.
legendary
Activity: 882
Merit: 1873
Crypto Swap Exchange
Aren't you tired already from playing it stupid? I mean, Jesus. Do you think the viewers of your discussions can't tell you're one big hypocrite?
At this point, any body who reads a discussion in which Kruw has participated and decides Kruw is to be trusted deserves the future consequences of their own stupidity.  Such as nodding their head in agreement to Kruw back when he pointed fingers at us for arguing against Censorship.  Whoever stood for the childish arguments Kruw had back then looks pretty silly now when you have Kruw himself running an uncensored coordinator, which is doing the exact opposite of what he said himself, which was that Censorship is the morally correct thing to do.

We both know Wasabi is NOT to be trusted and I would definitely have many other options over it.  Hell.  I would rather trust a Centralized Exchange which says up front that they impose Know Your Customer than some body like Kruw and the Services he advertises.  Particularly when equal or better competitors to Wasabi always get a spit in the face from Kruw with no reason when ever he gets the chance to do it.  I like people being up front.  Particularly when I decide whether to choose their product or not.  Tell me you arbitrarily ask for Know Your Customer and I will be an idiot if I drop my money thinking I will not be asked for it.  But when I ask a question and it always gets derailed, how the hell am I supposed to trust?  When Wasabi claims to be THE solution for Fungibility while differentiating one Bitcoin for another and THE Wallet for Privacy while imposing Censorship, which is very 1984 ish, how am I supposed to trust their product?

I forgot.  'Wasabi is TRUSTLESS!'.  Sure.  How dare I even THINK about trust.  I completely forgot their stance was different.  More like, ignore the red flags, shut up, close your eyes and hand us your Money.  Do not ask questions, or else you are an idiot.  And a Scammer, too.  And probably an Alt of Samourai.

Like I previously said.  Kruw could do astonishingly well as a Politician considering the expertise of avoiding any legitimate question, derailing discussions and talking about apples when asked about pears.  This is a skill no body wants but he proudly showcases at all times.

-----

Yes. Why can't you answer that question?
Why can you not answer so many questions and always answer only what is convenient?  The glasses, Kruw.  We are back to where we started, they are either dirty again or you need to get your eyes checked because they seem to skip so many questions all the time.  I am starting to get really worried!
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
You're really asking me to answer why I would rather use Whirlpool over WabiSabi

Yes. Why can't you answer that question?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Aren't you tired already from playing it stupid? I mean, Jesus. Do you think the viewers of your discussions can't tell you're one big hypocrite? You're really asking me to answer why I would rather use Whirlpool over WabiSabi, after all been said for the last two (or three?) years?

Literally everything in these questions has been answered in the past. Anyone still trying to figure out those answers can just use a search engine like ninjastic.space. The tl;dr is that Wasabi is a clown fest. I'd rather not engage in discussions about it anymore, if I may. I think I deserve this. There really isn't anything more to say.
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?

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

Still waiting for the answers to all of these questions.
Pages:
Jump to: