Okay, but that doesn't answer on why having arbitrary fee rate. The network could be flooded with transactions such that maybe 2500 sat/addy is neither enough.
We simply do not want to add more moving parts where they are not necessarily needed in order to improve stability. The backend and signers have to validate every single action and adding more friction at the withdrawal stage by making the fees dynamic doesen't seem like a good idea. We'd prefer to eliminate them altogether if this is really an issue, we want the system to work without ever needing our intervention and we achieved this in the current form.
Apologies for my difficulty to comprehend blinded certificates, but I still don't understand what prevents you from keeping logs which would give away the activity of the users. For example, I created a note and deposited money to an address tied to that note. You could have kept that. Then, when someone sent me money to my public address, you could have known which note was spent in which public address.
Unless the front-end is coded in such manner that prevents the unveiling of that information, I don't know how provable privacy is ensured.
It's a misunderstanding, Blinded Certificates are not implemented in the current version. I explained how it would work in Whirlwind's case in the messages I'll quote below, but we are not really in a rush to implement it as it's quite apparent most users don't care that much about this aspect.
I hate the word "revolutionize," so I mean it when I say that blind certificates could actually revolutionize the mixer industry. They're going to be important to understand if you're in this space, so as a weekend project, I tried my best to create an easy-to-understand explanation graphic. Of course my guide simplifies the info a little, but it's meant to explain this stuff to beginners. There's more to add at a later date, but this should be a good start!
Great explanation and I'm glad you found the idea interesting enough to allocate time for this!
I want to mention that while we certainly could store logs about every transaction and we can't prove that we don't, in case you believe that we don't then I'll tell you how the current system works: we only store a Notes public key and balance in the database, when you generate a Note that is its corresponding private key. So in the database the Notes are not stored in chronological order, it's random. There is no link between a Note's public key and its corresponding deposit because we don't store anything about that. If you want to take it a step further you could withdraw a small percentage of the Note or combine 2 of them together so you alter the link between the exact deposit amount and Note public key balance in our database.
Whirlwind is built in a way that makes it possible to implement Blind Certificates, as an example our version would look like this:
There will be 5 Blind Certificates denominations, 10
BTC | 1
BTC | 0.1
BTC | 0.01
BTC | 0.001
BTCEach one will have it's own Anonymity set, which means that if there are 100 x 1
BTC Blind Certificates issued, if you redeem one of them it could be any of the 100 issued certificates from Whirlwind's perspective. The only known information to anyone including us is that one of the 100 issued certificates was redeemed.
The flow looks like this: User deposits 1.1
BTC using the Note method and now holds a private key. With this private key he would then issue two Blind Certificates, one of them for 1
BTC, and the other for 0.1
BTC. Now his deposit is provably anonymous. Whenever he wants to withdraw, he redeems the two Blind Certificates for one or more Notes, and he follows the normal Note withdrawal procedure. In this case the user would be protected by 2 Anonymity sets, the public one which is the one that is now shown on the website, and by the Blind Certificates one, which proves beyond any doubt that you indeed got complete anonymity using the service.
For the moment I'll wait until people understand how Whirlwind works in it's current form and the service starts to see some more serious usage, and if this concept generates interest until then I'll implement it in a fairly short timeframe.
And here is a more technical explanation for why Blinded Signatures are not enough in Whirlwind's case and why we would need to use zk-snarks instead:
Our implementation would have to involve zero knowledge proofs and in short here is why:
We decided to use Groth16 ZK-SNARKS for this, instead of blind signatures, because of an important security problem in our architecture with blind signatures: if the private key which is used for the blind signatures is stored on the backend server, an attacker which compromises it would be able to forge certificates which the validators will trust, and therefore draining the wallet, basically making the backend+validator architecture that I explained in a previous message useless.
With a ZK-proof, the attacker would not be able to do this, because the secret witnesses used to prove a certain withdraw is valid is generated by the user in the frontend, so not even the backend can forge these proofs. At some point, we will make the frontend open source, which will reveal all of the backend’s endpoints, so you can build/host your own frontend for this, or even create a CLI.
The architecture would look like this: we store a merkle tree of the users’s public statements in the database. When a user redeems a note for certificates, we store the user’s public statements in the tree. When a user wants to redeem the certificates for a note, the frontend, using the user’s secret witness, will be able to prove to the backend (AND the validators) that he has the secret witness of a certain leaf in the tree, without actually saying which leaf it is. This makes it totally anonymous towards us, the operators, as well.