Hi LoyceV, thank you for your second feedback! We also apologize for the slow response; the low activity in this thread resulted in us prioritizing other important tasks and duties. Updates will be posted as soon as they are ready. We continue to be eager to hear your feedback and look forward to responding to it.
Using a third-party website to verify a signed message is terrible for privacy, but the site might work offline. I haven't been able to test that, because I haven't been able to verify the LoG. All I get is:
Signature Verification Failed
I'll continue
my review here. The delay is caused by me (Support Chat answered after 2 hours, I took 3 days to continue my testing):
Me:
Can you walk me through verifying the LoG on 8gwifi.org, or any external tool? I still can not figure it out.
Support Chat:
Of course! So first, visit the site
https://8gwifi.org/rsasignverifyfunctions.jsp. After that, select Verify Signature option first.
Public Key: Enter the public key in the LoG including -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----
ClearText Message: Enter the content of SIGNATURE FORMAT in the letter of guarantee, but without memberCode and so on. Only the content that comes one line after with your real member code and so on.
Provide Signature Value: Enter the content of the signature in the Letter of Guarantee. Here without -----BEGIN SIGNATURE----- and -----END SIGNATURE-----
You will also need to choose SHA256withRSA in the RSA Signature Algorithms below
Then it will show that the signature verification is passed
This verified the signed message. It might be good to add verification instructions to the website.
But 8gwifi.org's verification didn't work offline, so chances are the 8gwifi.org server now knows the details of my transaction.
After I verified the LoG, I made a deposit. I used a short delay to speed things up.
The public key is also in the footer of our website, which can be verified there. However, a detailed instruction to verify the letter of guarantee is a very good suggestion to increase the trust in our service.
When I checked my wallet after a while, it had 11 confirmations already. But the site (on Tor browser) still shows an animation and this:
Awaiting Confirmations
0.00xxxxxx BTC 0 / 2 Confirmations
If this can be fixed to auto-update, that would be great. I thought fees must have gone up, so I was still waiting until I checked my own wallet.
Reloading the page fixed it.
We have checked that already and it is auto-updated. However, some security options on browsers interfere with some features sometimes which lead to such situations.
After reaching Step 5 ("Done!"), I can't check back the earlier steps anymore for the exact details, but at Step 4 it showed that I would receive a slightly larger amount than what I actually received. The difference wasn't much (maybe 1000 sats), but this should have been the exact amount. The total fee is now about 50% higher than what it showed earlier.
The reason for this is because the transaction fees are deducted from this amount to send it to your provided wallet address. All steps before are also deleted because of security & anonymity reasons.
Suggestion: can you make the random fee provably fair? For instance, you can use the order ID and block hash of the incoming transaction as input to generate the random number. This might prevent complaints if someone is charged 3% on a large deposit. This can be prevented if both you and the user can't know fee before the deposit gets confirmed.
Of course, we have thought about it, but there are some issues that prevent us from doing so. The reason why we offer a randomly generated fee when mixing is because of the increased security that our users will have. Displaying the random fee before depositing will cause our users to create multiple order requests until an acceptable fee is displayed. And this will lead to a much higher workload on our servers, more addresses will have to be generated unnecessarily and more.
Coinjoin?Now the thing it's all about: a coinjoin transaction! The transaction I received had 1 input and 2 outputs.
Let me quote from
the website:
CoinJoin is a method where different people join together a single pool and together create a single transaction where each of them give coins as inputs and fresh & anonymous addresses as outputs.
This didn't happen. I expected my own deposit to join a pool of other transactions, and be included in the transaction that funds my withdrawal address.
I followed my withdrawal up the blockchain, until I got to
March 29, 2022. This is the first transaction that looks like a coinjoin. But if I follow it
a bit further, I get to many parent transactions that look the same, which makes me think the same funds are being used for several coinjoins in a row. This one is from
February 10, 2022 for instance.
To offer our clients a better and faster mixing experience, certain amounts of Bitcoins are already coinjoined and prepared in case the coinjoin doesn't finish during the waiting time. This saves time and still has the same result as freshly coinjoined bitcoins. For larger amounts, Bitcoins are getting coinjoined with the transaction made and this sometimes takes longer than the set transfer delay. So summarized, the Bitcoins you receive, whether they are coinjoined before and prepared for our clients, or freshly coinjoined, the result remains the same and the Bitcoins are anonymous. Actually, it even has a better anonymity level, as the coins you are receiving are never associated with this transaction. They are funds that are prepared from other users and our company funds, as we use our own funds to prepare coinjoined Bitcoins.
The entire concept of "UniCode" doesn't make sense when doing a real coinjoin:
With this UniCode we make sure that the same coins are not sent again to the same user in future mixing operations.
With coinjoin, I
expect to receive part of my own coins back. What you're doing now is what most "classic" mixers do.
That is correct, however, there are several coinjoin pools we are using. What the UniCode prevents, is that the user is not always in the same coinjoin pool. We diversify it for the user.
From
Terms and Conditions:
The service is provided on a non-custodial basis.
~
trustless CoinJoin
I'll get back to this later.
To conclude: it's not non-custodial, it's not trustless, and it's not coinjoin. I've said this before in a discussion with another mixer: you're in the business of trust. People need to be able to absolutely trust you're going to do what you say you're going to do. Now it looks like you're using buzzwords to inspire confidence. All in all this does the opposite: if you lie about things that I know for sure are incorrect, how can I trust you on other promises, such as not keeping any logs?
We already mentioned that the Terms & Conditions will be updated. We will update you in this thread when it's done.
One more thing: Support Chat rejects many normal characters, I can't say "can't" and I can't use (brackets). If that can be fixed, that would be great! It's annoying having to remove common characters for every message I post.This is right, however, this is also due to security reasons. We don't allow different characters in the support chat because of possible security breaches such as Data injection into scripts, code injections, XSS injections, SQL injections.
This completes my review. Sorry for doing it in several parts, but it was necessary to verify things before I could continue with confidence.
No problem at all, we really appreciate your detailed feedback again and will work on your suggestions. If there is anything else you would like to comment, please don't hesitate to write a comment again. You can also write in our
main thread to ensure fast replies. Thank you one more time!