A few statements in regards to all the above comments:
1. We always respond support requests via email within 48 hours, but even if that time is exceeded, we never leave any exchange-related messages without a reply. Any person claiming we didn't respond their email after a few days is telling a lie. In regards to support tickets - we might opt to not respond if the issue is apparently solved and user abandoned the ticket/order page right after his order was complete automatically, but all other tickets are usually responded within 48 hours (except non-order specific questions). In regards to SimpleX - only 1 person has access to it, who is on his usual annual vacations which happen every year. Who was a customer of our service in the past knows we tend to be slower in responses during this period of year. Anybody who expects a more responsive customer support service from us - please opt by other type of exchanges that have mandatory KYC but have awesome ChatGPT-powered support (Binance, Kraken, Bybit or so). We are a bit different kind of service not suitable for everyone and sadly without any decent competition.
2. NotATether's issue is not the "customer issue" at all, since his issue is related with affiliation account approval which is related to B2B relations only (not customer relations), which he didn't even combine with us prior to starting using it. After he used his auto-generated affiliation ID to earn a partner fee from clicks on his site, he started to use it directly without notifying us which is mandatory to have withdrawals enabled afterwards, since we do not simply approve them for everyone and have a right to reject approval. After he earned a bit in fees and realized he needs to ask for approval to enable automatic withdrawals, he contacted us to enable them and was kindly asked to wait for approval. He then decided to proceed with reputational damage and fearmongering in this thread, which invoked our personal decision to cease the current partnership with him after allowing him to withdraw his earnings to fulfill our part of the deal. When somebody decides to employ their forum influence to push on us this way - this is a guaranteed unilateral partnership closure from us.
3. Tor with HTTPS is more reliable than without HTTP, because it gives users a chance to verify the TLS certificate's fingerprint and confirm they are on the correct resource, since the certificate employed on the HTTPS version is signed directly by us and works similar to our PGP public key. Without HTTP it's very easy to become a victim of a phishing scheme, and since our project is often targeted by such, we recommend Tor users to prefer the HTTPS version with performing constant certificate fingerprint verification.
Now, on HTTPS over Tor security. Is HTTPS over Tor for .onion domains secure? Absolutely! Is HTTPS over Tor for .onion domains more secure than HTTP over Tor? Absolutely, in case you can confirm the TLS certificate belongs to the resource you are using. The "insecure" wording used by current Firefox branch (and therefore Tor Browser, since it's its fork) can be extremely misleading when users access HTTPS .onion sites over Tor, since most sites like ours will opt by using a self-signed certificated because it's still very complicated to get a certificate signed by known certificate authorities for .onion domains, therefore Firefox's default behavior is to mark any self-signed certificate as "insecure", meanwhile it can mean the opposite, like in our case. However there are some developments that soon might allow facilitated issue and verification of .onion HTTPS certificates (like this one
https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt).
Some people prefer HTTPS over HTTP for .onion domains simply because it multiplies their security factor by 2 and in case there is a hypothetical chance that Tor's standard encryption may fail (which is of course very unlikely), and since very few Tor users are PhD cryptographers and coders that can audit Onion Services protocol security (don't forget that it's VERY complex for an average cryptography expert, since it also requires expertise in network security), it's simplier to rely on additional security like HTTPS instead of Internet posts from Stack Exchange Security.
4. Our Tor domain is being DDoSed since the previous month, therefore access issues some users are currently experiencing are normal and will persist till the DDoS stops. Since the DDoS technique employed by attackers is targeting available circuits in the network (paths) ready to process client communication with the HS and not directly the HS, we are using multi-hop path distribution protection technique to make the resource available by assigning multiple Tor instances to as much as possible different circuits. One or a few circuit changes is everything users need to do to successfully access the .onion domain if it appears offline to them.
5. In regards to Cloudflare DNS used by our domain name, it was already answered by me a long time ago in exactly this thread and I don't feel like re-writing what I wrote already just because some don't understand the difference between the terms "DNS" and "reverse-proxy":
Hey @eXch.cc, according to what's said on your website. Your service is Cloudflare free. Definitely one of your biggest selling points for someone who is in search of some level of privacy when exchanging their coins.
But then you use Cloudflare DNS according to whois. Now I am not too informed about how websites work, maybe I may learn a thing or two here. Can't a Domain Name Server be used by Cloudflare to gain access to your website's traffic there by compromising client's privacy?
"Cloudflare free" usually means that a website doesn't use Cloudflare's reverse-proxy service to prevent exposure of their users to MITM and UX issues, however this is not related to Cloudflare's NS service used by our domain name.
The main role of nameservers (NS) is to serve DNS records, which in our case is the "A" record that points users to the IP address of our web-server when they lookup our domain name. We use Cloudflare's nameservers because they are reliable and fast due to their company's considerable infrastructure available across the globe. They also provide a Tor-friendly API which we use to manage our DNS records.
The only possible attack vector in this case is DNS record hijacking. It means that Cloudflare will have to change our domain's "A" record from our IP address to another one with a working reverse-proxy in order to intercept all the network traffic of our users (MITM). This attack is very unlikely to happen because there is no point to do this in our case, since anyone on the Internet will be able to detect a such event and also because we will receive an alert from our security monitoring system about a DNS record change and will simply switch our NS to somewhere else. It is also worth to mention that a fingerprint of the website's TLS certificate will change during a such attack, since there is no way they can retrieve the private key of our TLS certificate to use it on their MITM reverse-proxy. There is a browser extension called CheckMyHTTPS (
https://github.com/checkmyhttps/checkmyhttps) that is useful to detect HTTPS fingerprint changes, however not as reliable as the older Certificate Patrol (
https://github.com/tg-x/certpatrol) which was storing each website's certificate fingerprints locally to detect and alert about fingerprint changes later.
Such attacks are very rare to happen, but when they happen, they're usually some LE operations with enough gathered intelligence to know what to intercept that mostly go for website's operators (i.e. admin credentials) and not their users. Our management interface is not available via clearnet at all nor located at our public Tor HS either, therefore a DNS hijacking attack on our domain name would not bring anything useful to LE.
The most famous LE operations with this technique involved that come up to my mind were mostly targeting botnets, where they intercepted operators credentials that usually represent superior value for investigations in order to obtain ultimate evidence. Nevertheless, this technique is not popular anymore compared to cooperating directly with datacenter operators and upstream network providers. I recommend searching through KrebsOnSecurity blog for the "takedown" keyword to find relevant articles and to learn more about LE methodologies and strategies.
Source:
https://bitcointalksearch.org/topic/m.62841789 
