Topic: Trezor Suite will add a CoinJoin mixing protocol - page 2. (Read 630 times)

I wouldn't say that I fully understand the mathematics behind input registration, but, as far as I understand, using homomorphic Pedersen commitments adds an additional layer of protection against a malicious CoinJoin coordinator trying to map inputs and outputs. Because hiding input amounts itself during input registration doesn't make those inputs invisible; amounts are anyway revealed once the transaction is constructed and broadcast to the network. Moreover, as you have pointed out and zkSNACKs CEO Max Hillebrand confirmed in this interview:
"Mixing directly to a hardware wallet" is not what I meant.  But it's good to know that such an option exist.

I just use my own node, that's it...
Either by connecting SPV wallets to the electrs instance running on it or using it directly.

I don't use other servers with my Bitcoin wallets and services.

Why are we talking about closed source wallets? The Trezor is open source - hardware and software.

What do you consider as proof?
For me, their word is proof enough. https://blog.wasabiwallet.io/zksnacks-blacklisting-update/
In my humble opinion, the one speculating here is someone else.

I don't know, but how do you know which code is running on any servers for all other bitcoin wallets and services you use?
I am not defending wasabi or anything else, but someone running closed source wallet knows even less.
Sure, I am not trusting wasabi very much with their new coinjoin, but I wont trashtalk them without any proof... if someone want's to be speculation king...go for it

In reality you know jack shit about anything you use online or offline.
You are still running wiInd0ws OS crap in combination with closed source wallets and you are teaching us some lessons here, please give me a break

Yeah, but applying Pedersen commitments to blind amounts is exactly what Monero has done before.
Meanwhile satoshi was the first to apply PoW, Merkle tress and EC cryptography to create a decentralized currency.

Well no, and they are not the first to use zero knowledge proofs or KVACs either. But neither was Satoshi the first to use proof-of-work, Merkle trees, or elliptic curve cryptography.

I do know that you can do 'hardware wallet coinjoins' with a Passport device (probably others, too) and Samourai Whirlpool, through Sparrow Wallet, already since last year.
https://nitter.it/SparrowWallet/status/1441049974934892553

I don't believe they've come up with it themselves. For example, Monero uses it for a long time.
https://web.getmonero.org/resources/moneropedia/pedersen-commitment.html

What you've written is correct for Wasabi coinjoins, but their new WabiSabi protocol is different. You can read the full technical paper here: https://github.com/zkSNACKs/WabiSabi/releases/latest/download/WabiSabi.pdf. You can also read a simplified explanation here: https://github.com/zkSNACKs/WabiSabi/blob/master/explainer.md. WabiSabi does not place constrictions on transactions having equal amounts as the original Wasabi coinjoin protocol does, and uses Pedersen commitments to hide the input amounts.

Credit where it is due, what they have come up with is impressive, but unfortunately it is rendered completely useless by their surveillance and censorship.

As far as I know, only information about outputs is blinded; everything else is open for a coordinator to analyze. A CoinJoin coordinator verifies if provided inputs meet certain criteria, particularly, it checks if inputs haven't been double spent in the same round, haven't been spent before a round started, and that they have a sufficient number of confirmations (for coinbase outputs it must be more than 100, for others I think a single confirmation is enough), and more importantly, it checks whether those inputs contain a sufficient amount of coins to participate in a CoinJoin round. Without this special check, it would be a tough task to construct a transaction because (1) these transactions require equal amounts in the first place, and (2) the amounts should be sufficient to cover mining fees and coordinator fees. Also, the cost of attacking CoinJoin rounds would be very low - a nefarious actor could indefinitely interrupt mixing rounds by spending tiny amounts. So, I don't think blinding inputs would work out, at least not in an adversarial environment where no one trusts his neighbor.

I have no idea, either, but the Trezor team has confirmed on their Twitter that they are working on a CoinJoin implementation: https://nitter.net/Trezor/status/1566708740597972997, and Wasabi Wallet team is excited about "hardware wallet coinjoins."

It hides amounts in that it allows an individual user to include many inputs all registered from different identities, without allowing the coordinator to know those inputs are owned by the same user, and then specify outputs which total the same as the sum of all their inputs. It doesn't blind inputs in such a way that the coordinator can not still see which inputs are being used. And even if it did blind inputs completely during the registration phase, at some point they must be unblinded in order to create the final transaction, at which point they are vulnerable to surveillance and censorship.

It was a rhetorical question.

To be honest, I am not 100% sure right now how WabiSabi works, but in theory it uses zero-knowledge proofs for something. I just quickly checked and somehow it just uses it to hide amounts; but that wouldn't work if they wanted to implement a blacklist. They'd definitely need to know the UTXO hashes in cleartext to match them against such a list.
Which in turn means that no matter how they do it -- it's not even required for us to check the client-side code -- it has to provide them this information in one way or another.

I am not aware of them implementing anything in the realm of 'proving your UTXO is not in the blacklist without revealing the UTXO under zero-knowledge'. They have zkSNARK, but that doesn't cover this application.
Also, if they would (technically, it may actually be possible to do such ZK proofs), they surely would have announced that everywhere; at the very latest, when replying to our 24 questions. After all, they're so proud of their ZK proof that they put it into their company name. Implementing ZK into another aspect of their wallet would most definitely have been emphasized, no?

You don't. You only know what code is running in your local copy of Wasabi wallet, which isn't the entity doing the spying and so is irrelevant to the discussion here. As soon as you attempt to join a coinjoin through Wasabi's coordinator, your inputs are sent away to a third party server with who knows what code running on it. From there, you have absolutely no control over what happens to your inputs, where they are stored, who gets to see them, or which other third parties they are shared with.

Wasabi or their CoinJoin implementation being open-source has nothing to do with it. That's just a piece of software the end user works with. n0nce touched upon the subject. You have know way of knowing what's happening on a hardware-level and away from the piece of software you can download from the internet. We also don't know what is being checked, how it's being checked, and who does the checking. But Wasabi is not hiding the fact that it is/will be as you can see from o_e_l_e_o's quote of their documents. 

How do you know which code Wasabi is running on their servers, though?

I do know that CoinJoin somehow encrypts things under ZK so some things can be 'coordinated' by the coordinator without it seeing the actual data, as the operations work under ZK, too.

However, if the coordinator or the company they work with, had no way to 'see' the (cleartext) UTXOs, there would be no way to checking their history, right?
So Wasabi has to have a way of seeing your CoinJoin inputs in the clear.

I honestly don't know why you are blabbering about some secret government agencies, unless you had a very boring day  
If you are using closed source devices and wallets than you can speculate about this things much more.

Code is open source and haters would be first to expose this and report it everywhere.
Maybe ask owners od closed source wallets if they doing that with their secret signed NDA's and privacy policy third parties.
I still didn't hear a single case in the whole world that people complained about blacklisted transaction using wasabi, when I hear it I will be the first to report it here.
Till then I leave you to write fantasy fbiciami6 stories  

It's already in their legal documentation, so you can only assume it is already happening:

To effectively run a blacklist, you must first check every input to decide which ones you are going to censor. This invades everyone's privacy. The presence of a blacklist will discourage anyone who is serious about privacy from using the service, not just scammers.

I doubt that there really are or will be messages about blocking, because in fact, a statement about the presence of a blacklist in coinjoin will discourage scammers from using the protocol, and the blacklist itself can only be made public as a result of an internal leak or hacking.

It doesn't work that way. You can't have proof of everything and claim that the lack of evidence means such activities are not taking place. Can you show me proof of what the CIA or MI6 have done in the past 6 hours, what people they are looking into, and what actions are being discussed in their meetings? Does your lack of such proof mean they are not intelligence agencies?

How do you know that UTXOs and all its history are already not being checked, compared, exchanged, and stored in some databases somewhere to be used for who knows what? There isn't going to be proof for that and open-source or closed-source doesn't matter one bit for that to be the case.

The problem is that if they will / do already blacklist, a very low percentage of inputs will be affected. It's probably not going to be trivial manually forcing an input to be rejected.
That does not mean that user inputs are not already shared with their blockchain analysis company, though!

The problem is not that your input can get declined; in that case, you take another one and call it a day, sure. And if they don't do it yet at all, even better.
What we don't know is whether they're already sharing UTXOs with external companies before each and every CoinJoin. There has been no confirmation or denial of this information, yet.

Or someone could simply do one easy experiment with sending their coins to wasabi coinjoin and see what happens... if bomb will explode, special forces storm your apartment, and your transaction gets rejected for some reason.
Full disclosure, when I did my review of wasabi wallet few months ago I was not able to complete my coinjoin for unknown reasons, after trying for few days.
During this time there was some issue with Tor network so this could be one of the reasons.
One more problem I faced is that I was not able to connect Trezor device with wasabi wallet, and I was not the only one with this issue.

Do you count statement by WasabiWallet as proof[1]? If no, i doubt anyone can provide proof unless someone who works there become whistleblower.


I agree. It could be as simple as better Trezor support on Wasabi Wallet.

---

[1] https://blog.wasabiwallet.io/zksnacks-blacklisting-update/