Pages:
Author

Topic: Wasabi Wallet - Open Source, Noncustodial Coinjoin Software - page 34. (Read 11412 times)

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Same soundbites. Continuously engaging in strawman arguments. Over, and over, and over again, 'til the end of time. Deliberately ignoring my points.

Why are you so frustrated? I'm answering your questions directly, what point are you claiming I've ignored? Provide a direct quote.

You yourself have said that it's possible for a careful observer to tell that the 200/200/200/249 inputs are certainly connected with the 171 outputs.

Yes, I mentioned this is a particular case where non coinjoin transactions the user made in other wallets allow a careful observer (not the coordinator specifically, anyone with a copy of a the blockchain can observe this) to find out these inputs are owned by the same user:

In this particular case, a careful observer is able to determine the 200/200/200/249 inputs all belong to the same user because the change output from each of the 200 BTC coins were consolidated when creating the 249 BTC coin.

If the coordinator does not have this information, then you either lied about the input output connection (which you didn't as anyone can verify with basic blockchain heuristics), or the coordinator is not configured to be a careful observer.

I already explained to you that the coordinator does not choose the output amounts:

The coordinator does not dictate the output amounts, clients choose their own outputs.

Or, you know, the client software is problematic and chooses to waste block space because it can't tell before joining, that the 171 outputs are seemed as provably owned by one entity.  Roll Eyes

Why do you consider it problematic that the client is not aware of the transactions you did before you started using the client?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Same soundbites. Continuously engaging in strawman arguments. Over, and over, and over again, 'til the end of time. Deliberately ignoring my points. You yourself have said that it's possible for a careful observer to tell that the 200/200/200/249 inputs are certainly connected with the 171 outputs.

If the coordinator does not have this information, then you either lied about the input output connection (which you didn't as anyone can verify with basic blockchain heuristics), or the coordinator is not configured to be a careful observer. Or, you know, the client software is problematic and chooses to waste block space because it can't tell before joining, that the 171 outputs are seemed as provably owned by one entity.  Roll Eyes
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
The coordinator can check if the inputs and outputs are owned by the same entity

No they can't, coordinators don't learn that inputs or outputs in a coinjoin belong to the same entity. That information is hidden from the coordinator using cryptography and Tor.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Exactly, if the whale posted a screenshot of his wallet history publicly on this Bitcointalk thread, then Wasabi's software wouldn't preserve any privacy in that case either.
Peak whataboutism. The coordinator can check if the inputs and outputs are owned by the same entity, and is simply not configured to save the wasted space. You can choose to blame the user all you like, but that's the fact. 



In other news, Wasabi's default coordinator refuses to mix a "clean" coinbase tx0, because it flags their chain analysis filters.  Cheesy


(from: https://t.me/SamouraiWallet, in March 25)
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Strawman. I never claimed that by looking at the coinjoin you can tell that the whale inputs are controlled by the same user. But, information from past transactions does reveal it, and Wasabi software preserves no privacy in that case. Only wasted block space.

Exactly, if the whale posted a screenshot of his wallet history publicly on this Bitcointalk thread, then Wasabi's software wouldn't preserve any privacy in that case either.

Create lower value outputs that have less link probability. For example, instead of a 171.79 output, you could have 171 1.0 BTC outputs. Wouldn't it be more appropriate if it split the entire amount in a single round and then leave it for future remixes?

That would cost an enormous amount of block space to gain almost zero privacy for these outputs. The whale would not be able to merge several of these outputs in future payments without revealing the inputs that created them. Since there would be a >90% chance of guessing correctly with blind luck, it's better to wait for the next round and wait to use block space to create UTXOs that have a larger set of potential matches instead.

Additionally, allowing unbounded creation of outputs introduces a DoS vector. There's a "vsize credential" issued that prevents a malicious actor from trying to create an oversized coinjoin that doesn't fit inside the boundaries of Bitcoin Core's standard mempool relay policy or the consensus rules of the block itself.

Also, when you say "leftover change", to which thing are you referring specifically?

The 463.78287231 BTC output in bc1q3qtu3xgegsetnptn80cdjx5dmlkk7ephvdkhuw is leftover change created by the 469.06443079 BTC input from bc1ql7vr6ht0l7tqq803wedsdkalanjtswdna07wmf
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Exactly. When you just looked at the coinjoin transaction, you weren't able to determine these inputs were controlled by the same user since WabiSabi prevents input to input links from being revealed.
Strawman. I never claimed that by looking at the coinjoin you can tell that the whale inputs are controlled by the same user. But, information from past transactions does reveal it, and Wasabi software preserves no privacy in that case. Only wasted block space.

What should the client do then?
Create lower value outputs that have less link probability. For example, instead of a 171.79 output, you could have 171 1.0 BTC outputs.

So, if the difference between the whale and the next largest input is too large, it's best for the whale to just to keep leftover change to attempt in another round instead of aggressively trying split the entire amount in a single round.
Wouldn't it be more appropriate if it split the entire amount in a single round and then leave it for future remixes? Also, when you say "leftover change", to which thing are you referring specifically?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
They preserve nothing. It is trivial for everyone with a slight knowledge on blockchain heuristics to figure out that the 200/200/200/249 inputs are owned by the same entity, and therefore so are the 171.79. You pointed it out yourself. I don't do blockchain analysis, and that's why I didn't figure it out at the beginning. It drew my attention when you confidently said they are provably owned by one entity, a little after you proudly claimed that the whale went anonymous.

Exactly. When you just looked at the coinjoin transaction, you weren't able to determine these inputs were controlled by the same user since WabiSabi prevents input to input links from being revealed.

I never said the client should create a 687 BTC output instead of four 171.79.

What should the client do then?

What's "diminishing marginal returns"? First time hearing this.

In this transaction, the biggest whale with 42.9 BTC probably created 8 out of the 11 outputs for 5 BTC. Although there's a fractional amount of privacy gained on each of these outputs immediately from this coinjoin, the tradeoff is that the big whale can't merge several of these 5 BTC outputs for a payment in the future without indicating which input created it. So, if the difference between the whale and the next largest input is too large, it's best for the whale to just to keep leftover change to attempt in another round instead of aggressively trying split the entire amount in a single round.

And why didn't it work in the 200/200/200/249 coinjoin?

It did work in that coinjoin. An example of this "not working" would be the creation of an identifiable change output instead, which you can see in this coinjoin with a 469 BTC whale: https://mempool.space/tx/dd2c923c3cb73ea59e54f8319bab0b72c3a06abfe6cd517c8167957eecdf16a2

It took him 5 rounds until another big enough whale showed up to create large outputs without a direct link: https://mempool.space/tx/fb596c9f675471019c60e984b569f9020dac3b2822b16396042b50c890b45e5e
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
These extra outputs 171.79 outputs preserve the privacy of the 200/200/200/249 inputs by making them appear like they are potentially owned by different users.
They preserve nothing. It is trivial for everyone with a slight knowledge on blockchain heuristics to figure out that the 200/200/200/249 inputs are owned by the same entity, and therefore so are the 171.79. You pointed it out yourself.

You pointed this out at the beginning of our conversation
I don't do blockchain analysis, and that's why I didn't figure it out at the beginning. It drew my attention when you confidently said they are provably owned by one entity, a little after you proudly claimed that the whale went anonymous.  

If a 687 BTC output were created instead, that would definitively reveal the top 4 inputs were owned by the same user since there's no other combination of inputs in the round that could create an output that large.
  • I never said the client should create a 687 BTC output instead of four 171.79.
  • The top four inputs are definitely owned by the same user regardless if the output was a 687 BTC or four 171.79.

Why don't they get divided in small amounts in the first place? If you follow the remixes, you can notice that the amounts are still big. It would be more appropriate if instead of four 171.79 outputs, there were more lower in value outputs, which could be probable suspects for the other inputs as well.

There's diminishing marginal returns for each clone of a the same denomination you create. The behavior you are describing is exhibited in this coinjoin transaction with a medium sized whale: https://mempool.space/tx/9944645e87447262a6c8c4cdc3914a86b06c238809f8b7cb433c4a5fbd34fa2f
What's "diminishing marginal returns"? First time hearing this. And why didn't it work in the 200/200/200/249 coinjoin?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Even that way, shouldn't the client prevent wasting that block space? Why would the client allow you to join coins that will not get better in terms of privacy?

These extra outputs 171.79 outputs preserve the privacy of the 200/200/200/249 inputs by making them appear like they are potentially owned by different users. You pointed this out at the beginning of our conversation:

How do you know there is a whale of 850 BTC? I see four separate inputs of 200, 200, 200 and 249 BTC. Couldn't there be four people with the respective inputs separately instead of one?

If a 687 BTC output were created instead, that would definitively reveal the top 4 inputs were owned by the same user since there's no other combination of inputs in the round that could create an output that large.

Why don't they get divided in small amounts in the first place? If you follow the remixes, you can notice that the amounts are still big. It would be more appropriate if instead of four 171.79 outputs, there were more lower in value outputs, which could be probable suspects for the other inputs as well.

There's diminishing marginal returns for each clone of a the same denomination you create. The behavior you are describing is exhibited in this coinjoin transaction with a medium sized whale: https://mempool.space/tx/9944645e87447262a6c8c4cdc3914a86b06c238809f8b7cb433c4a5fbd34fa2f

What I don't like about Wasabi coinjoins is that the outputs don't have the same link probability. A 5000 sat output doesn't have the same link probability with a 10 BTC, because the former can be produced with any combination of the inputs, as opposed to the latter. (i.e., any input and combination of inputs can create a 5000 sat output, but not a 10 BTC, because for example, a 1 mBTC cannot create a 10 BTC output alone).

There's a "MaxSuggestedAmount" value given for each round and a minimum allowed amount. You could coordinate a "whale round" by adjusting these parameters.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
The coordinator does not dictate the output amounts, clients choose their own outputs.
Even that way, shouldn't the client prevent wasting that block space? Why would the client allow you to join coins that will not get better in terms of privacy?

Even if the 171.79 outputs didn’t gain any privacy in this round, they still needed to be divided into smaller amounts to gain privacy in further rounds.
Why don't they get divided in small amounts in the first place? If you follow the remixes, you can notice that the amounts are still big. It would be more appropriate if instead of four 171.79 outputs, there were more lower in value outputs, which could be probable suspects for the other inputs as well.

What I don't like about Wasabi coinjoins is that the outputs don't have the same link probability. A 5000 sat output doesn't have the same link probability with a 10 BTC, because the former can be produced with any combination of the inputs, as opposed to the latter. (i.e., any input and combination of inputs can create a 5000 sat output, but not a 10 BTC, because for example, a 1 mBTC cannot create a 10 BTC output alone).
sr. member
Activity: 1680
Merit: 379
Top Crypto Casino
Why should it spend an input to create another output with no added anonymity score?

Even if the 171.79 outputs didn’t gain any privacy in this round, they still needed to be divided into smaller amounts to gain privacy in further rounds. This whale also registered an additional 200 BTC in another round for a total of 1050 BTC. When most rounds have well under that amount in total liquidity, reaching the 100% privacy target is going to be a long process and there will be some large coins which might not gain much privacy initially.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
And the question remains. Shouldn't the coordinator check and prevent the waste of 4 inputs and 4 outputs in the WabiSabi coinjoin?

The coordinator does not dictate the output amounts, clients choose their own outputs.

If it displays an anonymity score of 1, then it means it's already analyzed that the 200/200/200/249 inputs make the 171.79 outputs, otherwise it'd return slightly more than that (25% chance for each). Why should it spend an input to create another output with no added anonymity score?

To a naive outside observer, the anonymity score of the 171.79 outputs is 4. It's only possible to determine the 200+ BTC inputs have a common owner due to the change merged before the coinjoin took place, but the whale's client knows it owns all those UTXOs regardless.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
He did go anonymous. There's an additional ~40 BTC in liquidity from other users in the round that obfuscates the ownership of the outputs smaller than 171.79 BTC.
Right, sorry. About 5% of their coins were anonymized. My bad.  Roll Eyes

The user doesn't get the impression the coins are private, the 171.79 BTC outputs still have an anonymity score of 1 and keep the original label from the origin transaction.
And the question remains. Shouldn't the coordinator check and prevent the waste of 4 inputs and 4 outputs in the WabiSabi coinjoin? If it displays an anonymity score of 1, then it means it's already analyzed that the 200/200/200/249 inputs make the 171.79 outputs, otherwise it'd return slightly more than that (25% chance for each). Why should it spend an input to create another output with no added anonymity score?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
This contradicts your other post, in which you claim that the whale went anonymous.

He did go anonymous. There's an additional ~40 BTC in liquidity from other users in the round that obfuscates the ownership of the outputs smaller than 171.79 BTC. Then, the 4 leftover 171.79 BTC outputs finished reducing into untraceable coins in each of the following rounds they remixed in.

Shouldn't Wasabi software automatically check and prevent what just happened? It is the user's fault to consolidate the change of the 200/200/200/249 outputs, but it's Wasabi's fault when it wastes block space and gives them the impression that their coinjoined coins are now private.

The user doesn't get the impression the coins are private, the 171.79 BTC outputs still have an anonymity score of 1 and keep the original label from the origin transaction.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
It'd be more block space efficient if it'd done that, yes, but in both cases the whale gains no anonymity. The probability of these 171.79 outputs being owned by the whale is 100%. The sum of the inputs after the 200/200/200/249 inputs is about 40 BTC, meaning that no other participant could have created an output of 171.79 BTC.

Correct.
This contradicts your other post, in which you claim that the whale went anonymous.

If the whale had not linked his change outputs together outside of the coinjoin, then the probability of guessing a 171.79 BTC output belonging to any specific 200+ BTC input would be 25% instead since they could potentially come from different users.
Shouldn't Wasabi software automatically check and prevent what just happened? It is the user's fault to consolidate the change of the 200/200/200/249 outputs, but it's Wasabi's fault when it wastes block space and gives them the impression that their coinjoined coins are now private.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
It'd be more block space efficient if it'd done that, yes, but in both cases the whale gains no anonymity. The probability of these 171.79 outputs being owned by the whale is 100%. The sum of the inputs after the 200/200/200/249 inputs is about 40 BTC, meaning that no other participant could have created an output of 171.79 BTC.

Correct. If the whale had not linked his change outputs together outside of the coinjoin, then the probability of guessing a 171.79 BTC output belonging to any specific 200+ BTC input would be 25% instead since they could potentially come from different users.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
However, the coinjoin amount decomposer behaves as if these coins have different potential owners (creating 4 outputs of 171.79869184 BTC), so it would have been more block space efficient if the whale had just created a single 850 BTC UTXO.
It'd be more block space efficient if it'd done that, yes, but in both cases the whale gains no anonymity. The probability of these 171.79 outputs being owned by the whale is 100%. The sum of the inputs after the 200/200/200/249 inputs is about 40 BTC, meaning that no other participant could have created an output of 171.79 BTC.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Two questions of mine.

  • How do you know there is a whale of 850 BTC? I see four separate inputs of 200, 200, 200 and 249 BTC. Couldn't there be four people with the respective inputs separately instead of one?
  • Isn't it apparent that the 171.79869184 BTC outputs are likely related to these four inputs?

In this particular case, a careful observer is able to determine the 200/200/200/249 inputs all belong to the same user because the change output from each of the 200 BTC coins were consolidated when creating the 249 BTC coin. However, the coinjoin amount decomposer behaves as if these coins have different potential owners (creating 4 outputs of 171.79869184 BTC), so it would have been more block space efficient if the whale had just created a single 850 BTC UTXO.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Two questions of mine.

  • How do you know there is a whale of 850 BTC? I see four separate inputs of 200, 200, 200 and 249 BTC. Couldn't there be four people with the respective inputs separately instead of one?
  • Isn't it apparent that the 171.79869184 BTC outputs are likely related to these four inputs?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Pages:
Jump to: