Why don't you answer my E-Mails since weeks?
I am waiting now for weeks for my money. The service said the transaction was sent but in fact it was not and my money just got detucted.
Please check your email, we should have responded now. Apologies.
For those curious, the transaction was never propagated due to a flaw in our fee selection, as it was somehow below the min relay fee. We hope to have fixed issue this now.
I also reversed other requests in background: All incoming and outgoing transactions are transferred without any extra encryption directly through cloudflare... So if cloudflare would record all the traffic it would be very easy to trace back all transactions.
See how it works on my outgoing, non-existing transaction:
Well yes, but not quite: see, apart from browser headers and your ip, there is
in theory nothing that connects your deposit to your withdrawals, as we use blind signatures in order to break that connection.
However, if you restore (resync) your wallet you will indeed make it very easy for us to infer what deposits and withdrawals belong to you, as you are querying them in quick succession.
This is a real problem we are not entirely sure how to tackle yet. Perhaps we could only allow you to restore your wallet at a certain time of day, so as to make it impossible for us (and cloudflare) to guess if there is just 1 individual restoring, or multiple.
Thats the same way how incoming transactions are checked... Just using another subdomain... "very secure"
Maybe when using TOR those two subdomains are connected to using different ips but was far as I have seen for now its not like the service is used by hundreds of people at the same time, so because of this and using other header parameters by the browser i am sure it would be possible for a child to figure out which request and wallet belongs to who. In my opinion this is not acceptable.
Indeed, it is quite trivial to guess which input belongs to which output, and really boils down to simple probability, especially with a small set of active coins (unused blind signatures).
We acknowledge this. The only way to really overcome this is by growing our userbase. Yes, we could also impose additional restrictions such as not allowing you to withdraw random amounts, or forcing you to wait some time before withdrawing, but that would probably be detrimental to the UX.
Because of it the mixer is not that blind as you describe. You could also easy track it back by headers and time. To make the whole thing make a sense you should encrypt the data in the browser somehow using keys only your server and the client nows.
We have thought about encrypting the data before sending it to our server and we might revisit this soon because indeed, there are not really any cons apart from the fact that it
does not really improve your privacy, but rather gives you the illusion that it does since
we can still see your ip and headers associated with an action and connect the dots.
There is really no way around it, to attain privacy
you as the client will need to be proactive as well. Use the tor browser and rotate your IP between deposit and withdrawal. Wait a little bit before withdrawing, and don't withdraw the same, close, or division of the original amount.
And the whole "blind" thing can't work ever in my opion. Because your server always will know incoming and outgoing transactions to validate. So why don't focus on better mixing? I see people here and also I experienced receiving my coins back. Who needs a mixer where this happens?
You still might be misunderstanding what blindmixer offers: we don't
know the inputs associated with your unblinded coins (though we can of course infer), not just as a promise, but as a fact.
As a result it can happen that you receive your own inputs back, because we do not associate them with "
you"; that is, your original deposit. It would be impossible for us to do so due to our usage of blind signatures.
Everyone should want a mixer where this happens as a result of using blind signatures, because it is a
symptom of providing true privacy, and not one that is merely based on promises.
I really like the idea of the service, but for the rest it is not usable for production.
There is a lot work to do in improving privacy and you should make the raw transaction code viewable for the sender, so when your node fails to broadcast they can do it manually.
We could indeed push the raw transaction hex to users, but it would not have helped in your case as the transaction was simply invalid.
Apologies again and agreed, there are still a lot of bugs we need to iron out and plenty of ways to improve the current product.
