Topic: [ANN] Anonymixer - the Anonymous Bitcoin Mixer - page 3. (Read 2612 times)

Hi Gary,

Thanks for your kind comments.

I have written some custom local software which allows me to view / manage the state of Anonymixer as well as digitally sign cold transactions prepared by the system.

Unfortunately, A bug in this hardware interface / signature code presented itself the other day and will continue to happen if an unsigned transaction has certain properties. Until I've fixed this bug, I'm not comfortable with Cold Trades so I've turned them off for the moment. This fix is currently Priority #1 and I am working on this, even now, I will re-enable cold trades once this code has been fixed. UPDATE: now fixed

I initially set the Cold Limit down to 0.2 BTC, then to 0 BTC, where really I need to set a config flag, similar to Issue #1, where by there's a nice message explaining that the Admin is currently unable to accept Cold Trades and/or is away at the moment.

Regarding other (Hot) trades and speed, this is down to the Mempool. Once a Trade has been fulfilled by the user (i.e. all deposits have at least 1 conf) and they want their outgoing transactions to be sent absolutely immediately, that's totally fine and they'll go out immediately, with a good fee and get confirmed quickly.

The Bitcoin mempool right now is quite congested. Some transaction deposits sent without enough of a fee on them will take longer to confirm. However, if you've sent a Transaction with "Replace-By-Fee" enabled, you could re-send that Transaction with a higher fee and hopefully it'll confirm faster.

I hope you are enjoying the Bitcoin Price rise that has come hand in hand with the Mempool being busy, Gary

UPDATE 2020-12-19: Cold Digital Signing code is working, all unit tests passing, have to perform end-to-end testing and then will re-enable cold trades later today. Thank you for your patience.
UPDATE 2020-12-19: Cold Trades have been re-enabled.

I'm happy to report several successful mixes using this service. I do have a couple of questions though.

I am in a mix right now that limited me to .2 BTC and I think I know why, but the WARNING! message that pops up is unhelpful in explaining why and is a bit disconcerting.

Also the first few mixes I did were done very quickly but then it seems like they got progressively slower until the present mix I am in has been over 12 hours.

Nice service... just wondering...

nah, i didn't... I phrased it wrong... I meant to say something more in the lines of :"It's been a while since I last posted in this topic, and because i didn't want any bias, i didn't re-read everything before i made my review".


Agreed, so far i see a lot of green lights for this one... It is indeed refreshing to see a mixer that doesn't fall for the obvious pitfalls so many others have fallen for lately. I still won't give up chipmixer and coinjoining using my wasabi wallet, but i'll defenately keep this one on the shortlist after the OP makes the changes to allow me to specify the amount i want to deposit instead of the amount i want to withdraw (he seems to be working on this feature), and i'll defenately use him to mix unspent outputs that are not ideal for chipmixer or coinjoin (unspent outputs with values that make them less suitable for their algo).

Did you forget you posted here before?

I've seen many mixers that claim to own 200 or more Bitcoin, and claim you can mix 50 or more Bitcoin at once. And I've seen some of them disappear the moment someone deposited a large amount.
It's refreshing to see a mixer that doesn't make large claims about owning funds, and doesn't seem to be hoping for a large deposit to run away with.

full disclosure: i'm payed the equivalent of ~$15 as an incentive to do a small writeup of anonymixer.com

preface: by sharing screenshots of the mixing process i went trough, i basically voided my mixing session. I also made other "bad" choices opsec-wise (like chosing a short interval and only creating 1 deposit and 1 withdrawal addy). The point is that i'm trying to review this mixer, not mix my unspent outputs . You're free to lookup these addresses on any block explorer and see if the mix was actually succesfull

preface 2: i'm also a big fan of using tor to initiate a mixing session, aswell as using a non-js mixer (this function is available in this mixer), however, i decided to use the clearnet, js-enabled version from my normal browser, since this is the way i suppose most normal non-tech users would use a mixer

preface 3: i did not read the other posts in this topic, so i wouldn't be prejudiced.

preface 4: i use wasabi to hold some pre-mixed change before i move my funds to my hw wallet... I'm not here to start a discussion about this... Wasabi is fine for holding smaller amounts, as is electrum... Desktop wallets are not ok for long term storage.

Here we go:
Walktrough
1) I created a new address where i liked to receive my mixed funds:


2) I opened anonymixer, pasted the address i created in the first step and chose the amount i wanted to receive post-mix


3) I was redirected to a page where i had a nice overview of the costs, and where i was able to adjust the timeout


4) I was redirected to a page where i saw 2 deposit addresses and a proposition on how to divide my funds over these 2 deposit addresses. I removed one of these addresses for the purpose of this walktrough, but it's better opsec not to do this. The page also allowed me to download the letter of guarantee both in txt as pdf format


5) I deposited the necessary funds


successfully


6) The unconfirmed tx was picked up really fast by anonymixer's gui


7) I waited for 1 confirmation, at this time my 4 minute timeout started counting down




After the 4 minute timeout, i received my mixed funds


Discussion/remarks:
1) I've already contacted anonymixer after completing this mixing session because i tought it would be better if they allowed me to specify how much funds i was going to deposit instead of having to specify how much funds i wanted to receive post-mix... I usually start with an unspent output i want to anonymise. Because of the random fee, it's impossible to calculate how much i have to enter as post-mix value in order to spend the complete value of the unspent output. Underestimation leads to tainted unspent outputs funding my change address, overestimation leads to having to use an extra unspent output.
Apparently the owner was already aware of this, and had already opened a ticket in his git repo about this issue aswell

2) I tought anti-csrf tokens were missing, but apparently they are not... my bad

3) I was missing some security headers, i have sent them to the OP. Nothing dramatic tough, just small tweaks... Not all headers are necessary, but it's wise to consider them on a case-by-case basis. I guess this mixer would be fine even without these headers, but i was in a mood to nitpick

4) The session cookie missed the secure flag

5) native segwit deposit addresses would have been nice...

6) the canary function is a nice touch, eventough 2 weeks time between 2 updates might be a tad bit on the long side... But at least we'll know in 2 weeks or less if the OP ever goes AFK for a longer period of time.

Conclusion:
From my point of view, the OP did his homework... I'm 99,9% sure my own site has a lot more vulnerability's and is missing a lot more security headers than OP's.
I'm glad to see a new mixer that doesn't include external js, doesn't use a CDN, doesn't created a MITM by using cloudflare,...

From a technical point of view, I can say that anonymixer looks really promising. There might be some bugs here or there, or some enhancements,... but nothing to serious, and AFAIK nothing that exposes this mixer's clients.

I waited a couple of days after being contacted by the OP, there is no way he knows I was starting my walktrough, and everything went exactly as i presumed it would go... So, i'm confident in saying the OP at very least has the infrastructure to do what he's claiming to be doing.
Offcourse, mixers need to stick around for a while to build some trust, trust is something i cannot review... But in this case, at least i'm hopefull... This is a mixer i would actually use myself from time to time. I think this one of complementary to chipmixer since these mixer's have a completely different mode of operations

PS: Since i voided my own mixing session, i'm also willing to share the letter of guarantee i got, so people are able to verify everything for themselfs: https://www.mocacinno.com/hotlinkimages/anonymixer/1e2289b0-a4c7-427d-87a0-84bf58983dac.txt
I went ahead, and verified the signature, it's valid... But you're free to try it for yourself

Thank you very much LoyceV for reviewing Anonymixer. it's really appreciated!


I've created Issue #1: Add "System Maintenance" flag mechanism which means no-one will face that in the future once completed.
Unfortunately, despite the tx creation/coin-selection code working just fine for weeks, After noticing odd things in the logs, to be on the safe side I decided to stop accepting new trades by setting the maximum limits to 0 whilst I had a closer inspection.


Totally agree about that not being intuitive, I created Issue #2: Clicking Confirm "tab" destroys user's entered data. Now fixed.


Agreed. The maximum limit should be more prominent. I'm going to have a think about showing users the maximum limit, closer to output addresses. These limits were previously visible on the Outputs Screen prior to adding in the marketing material.


You want to avoid sending change to yourself, which is very understandable. This would require a bit of deep surgery on my part, which can done. I've created Issue #4: Ability to update Output Amounts on Confirm screen in-case you would like to track that feature's progress.


As things stand, the trade would expire - which is bad. However, providing we have a Letter of Guarantee, any trades can and will be completed manually. I've created Issue #5: Extend the life of trades with low-priority unconfirmed transactions which should help even if incoming deposits are coming in with 1 sat/byte during a high fee season.


Quotes last for a maximum of 30 minutes before they time-out and where you would be presented with an updated grand total / set of fees. However, I agree this is odd to look at and a user should be given exactly 72 hours from the moment they press the Confirm button. I've created Issue #6: Trade Timestamps on Confirmation of Trade.


Let's see how things go, things can change. At the moment, I'm personally in favor of a variety of UTXOs both large and small. More UTXOs to choose from is better for the coin-selection / transaction creation code in terms of both getting lucky with change avoidance as well as when we do have to create change, doing so in such a way that makes it very difficult or impossible to spot which are the change outputs(s).


We also believe transaction fees should be as low as possible, but bear in mind that trades wait for deposits within a 72 hour time window. The mempool may be relatively empty at the point-in-time they create the trade, but it may be busy when their final deposit confirms and/or their scheduled outgoing transactions are due to go out (say 40 hours later). So we must be conservative, but not overly conservative if that makes sense.

On the plus side of being conservative like this, it means that even during times of high fees, users who want to get funds mixed, can do so quickly.

I have created Issue #7: Add ability to adjust Bitcoin Network/Mining Fees on Confirm Screen, in-case you wish to track this feature.

Just a note, Outgoing Transactions which are due to go out at the same scheduled time do in-fact go out in the same batched transaction, which reduces network/mining fees.


I will get that sorted. I've created Issue #8: FAQ: Maximum Fees should show actual real-time fees, not just a picture.

• Many wallets
• Many UTXOs in each wallet, e.g. 100+ per wallet
• It is Wallets, but not UTXOs are cycled in chronological order

The code tries it's best to not combine UTXOs in outgoing transactions, however that can happen, of which it would be unlikely to pick another deposit UTXO from the same trade due to the amount of UTXOs available within a Wallet.

For the moment, one could ensure that UTXOs can not be co-spent if they happen to both originate from the same deposit input transaction, but we could not follow the same logic across multiple input transactions as that would mean keeping a permanent record of which UTXOs were linked to which trades, which goes against the 100% no-logs policy. We could however try to influence it so that UTXOs in the same Wallet with more disparate block heights are preferred as potential partners as opposed to those confirmed closer to each other. We will continue to have a think about this.

What we can do and actually do manually, from time to time, is shift coins around internally, not co-spending any of them in a variety of ways.

For internal UTXOs "at rest" not associated with any users or trades, we were previously thinking about writing code to participate in JoinMarket CoinJoins as a Maker or connecting to a Wasabi co-ordinator node and joining in with their CoinJoins, but for the moment have decided against this because of the possibility of exchanges then flagging-up coins that have come from Anonymixer as being suspected of participating in CoinJoins, because they would've been. So internally shifting stuff around for the moment is the weapon of choice.


We know you like the Lightning Network and in this case you were sending some funds to your Pheonix Wallet, presumably to open a new channel. It may or may not interest you to know that we've been working on adding Lightning into Anonymixer.

The suggestion is, in the future you could give Anonymixer a Lightning Invoice on the Outputs Screen and then send a regular on-chain deposit to Anonymixer which would then pay your Lightning Invoice(s), re-balancing and re-populating your existing open channel(s).

Likewise, the reverse: say you have received many payments via Lightning and can no longer accept funds into these channels and wish to on-chain some of those funds without closing your channels, you could deposit funds to an Anonymixer Deposit Lightning Invoice(s), which would result in your chosen on-chain Output Addresses getting regular Bitcoin payments.

I was asked to test Anonymixer, and received 0.001BTC to use for this.

My review
I used the Tor site.
After I entered 3 Output addresses (all Bech32), I clicked the gray Confirm tab. This emptied my Output addresses and I tried to enter them again. It showed red: "Warning: Your maximum limit right now is 0 BTC. Please reduce the total Bitcoin."
This error didn't go away, even after reloading or trying in a private Tor window. It turns out something went wrong on the site. After anonymixer fixed the problem, they said they've added a "maintenance mode" so it becomes more obvious when the mixer is taken down in the future.

Trying again, the same thing happened when I clicked the gray Confirm tab: this emptied my Output addresses again. I think this should be fixed, I get now that I have to click "Continue", but I intuitively assumed going back and forth through the tabs would work.

It took me a while to notice the Maximum amount that can be mixed in the bottom-left corner. It's a lot of scrolling to get there, maybe this can be placed closer to where you enter the Output Addresses.

I don't like that I can't change the amounts sent to each address on the Confirm tab. I want to spend a certain total amount, but I have to go back to get to the Outputs tab to adjust for the Bitcoin Network Fee and Anonymixer fee. It would be better to show the Total amount including fees on the Outputs tab. Now it's difficult to get to the right amount, because everytime I go back, the Bitcoin Network Fee changes. I'm probably not the only user who wants to send an exact amount so I don't receive a small change amount.

I've deposited funds to 2 different deposit addresses with a low fee (7 sat/byte). I'm requesting it to be send to 2 different addresses (straight into my BlueWallet and Phoenix Bitcoin Lightning Network wallets).
Hypothetical question: what would happen if my transactions don't confirm within 72 hours?

I didn't change the default delay between output transactions, and the first transaction arrived as scheduled already. The next transaction was scheduled 31 minutes later. Eventually they both confirmed in the same block, despite a delay of 31 minutes in between (the default). Blocks are sometimes slower, so a larger default delay might be better.

Letter of Guarantee
I confirm this checks out. A question though:
I guess the 72 hour started when I started entering data on the site. It's a small difference now, but if someone takes 2 days making changes, this shouldn't be taken from his 72 hours. So I suggest to add exactly 72 hours from the moment the Letter of Guarantee is created.

Other comments
For your business model: you're currently not charging any additional fee when someone funds 20 different addresses, while the cost for you will be higher. As an example: CoinPlaza.it (a small exchange) used to charge no mining fees on Bitcoin, but they've changed that. For several of my past transactions with them they earned less from me than they paid on network fees alone. So I wonder if this will be sustainable, especially when transaction fees rise a lot.

Sending individual output transactions also increases fees a lot, and I think you're overpaying miners. Especially if you target small amounts, transaction fees should be as low as possible. One third of the fee would still have been enough for a fairly fast confirmation, and in most cases I prefer lower fees over faster confirmation.

In the faq, it shows a screenshot of the maximum mixing size. This is an "Example", but I'd suggest adding real-time values instead of a picture. Make it show the actual values. People usually don't read, so the images is the first thing they'll see.

Also from the faq:

Hi everyone,

Just to let you know that on Saturday 28th November at 23:00 UTC
our front-facing web server will be down for scheduled maintenance.

Estimated downtime is likely to be 1 hour, but could take longer
and may not be up until some time on Sunday.

No existing in-flight Trades will be affected and will go through as normal
regardless of whether or not the front-facing web server is up.

It is likely that the two two Onion URLs will be up and accessible
first before the Clearnet URL, just a reminder, these are:

V2 Onion: anonymixerpolbpy.onion
V3 Onion: btcmixer2e3pkn64eb5m65un5nypat4mje27er4ymltzshkmujmxlmyd.onion

Regards,

Anonymixer

Message written at Bitcoin Block:
0000000000000000000bfbf9d885a9bfbd55267bd10767488f2b210248b25340

---

Signature: IHhF3yZiFm0mpfAPzpaYLKWr1P5qoTsinwSX6yITFP9BY9nzbMAXbM3KwDIMCIfgAnyzaFpguZMMYRF Tn9a7gsw=
Signed By: 1AnonyMix35XkzRusC7FAzwi9KKggnyg5b

Hi Everyone,

We've been updating our site and fixing bugs.

• The site works better and smoother than ever without JavaScript
• We have added an Onion V3 Address
• We have added Russian and Dutch Language Translations - (Big thanks to Royse777 for the Russian Translation!)

A reminder of all of our URLs,

Clearnet: https://anonymixer.com/
Tor Onion V2: http://anonymixerpolbpy.onion
Tor Onion V3: http://btcmixer2e3pkn64eb5m65un5nypat4mje27er4ymltzshkmujmxlmyd.onion

Interesting comment anonymixer. As of today I got almost 95% of my coins under strict coin control. Nonetheless I am studying what could be the best options to keep my privacy and avoid blockchain analysis as I believe in the not so distant future LN and such will be more ready to be used on a daily basis. Either way, what can be done with your service looks good and I will try it eventually.
I'm glad you will be adding references not only for Wasabi, as there are more ways of producing toxic waste. 
I'll see you around (sorry can't merit, I am out, will keep some for you)

Hi Karartma1,

Yes, the same applies to Doxxic Change produced from Samourai Wallet CoinJoins. Thanks for letting me know about this, as I'll update the site regarding that!

This actually applies to any small coins/outputs you have, where you consider them to be dangerous from a privacy perspective.

• Small coins/outputs can be too small to practically spend on their own in one go, yet when combined can add up to a very significant amount of money.
• If you co-spend any of these outputs at the same time, you destroy your privacy as Common-Input-Ownership Heuristic analysis will let any outside observer know that you in-fact own those outputs.

Because Anonymixer provides you with 20 unique deposit addresses per trade, you can spend each of your low value coins in their entirety (seperately), sending each in separate transactions to respective unique Anonymixer Deposit Addresses with no change.

As far as outside observers are concerned, each of these individual transactions is considered to be a straight "internal transfer" from one Address to another. i.e. sending them to yourself.

Once you've sent your deposits to Anonymixer, you will then get a consolidated coin back that is entirely unconnected from any of the coins you sent Anonymixer in the first place.

No matter how much Blockchain Analysis companies try to piece models of clusters (wallets) together by using common input ownership heuristics / peel chains / change address identification etc, they will never be able to determine that you either sent your coins to a mixer or received a consolidated coin back from a mixer - They can't identify any of our clusters or addresses!

All transactions look like regular transactions between users.

Let's say you have 5 low value coins/outputs:

• 0.00014642 BTC
• 0.00053470 BTC
• 0.00023380 BTC
• 0.00051851 BTC
• 0.00051346 BTC

You create a trade and send 5 payments to Anonymixer, to 5 unique deposit addresses. Spending each individual coin in it's entirety with no change.

Anonymixer will then send you back 1 coin = 0.00194689 BTC (minus fees).

Don't throw money away to Bitcoin Eater Addresses.
Every Satoshi is Sacred!

More information can be found at: https://anonymixer.com/help/wasabi-change-coins

Please specifically look at the area: There is a Solution - with Anonymixer

I guess the things I like the most are no JS, being mobile friendly, no CDN, no HTTP and of course TOR Support. I have a question regarding Wasabi toxic waste: could the same be done with the doxxic change coming from Whirlpool (Samourai Wallet)?

Hi Everyone,

It's been a while since the last post.

The Anonymixer website front page has been revamped, bells and whistles have been added. Any feedback is most welcome.

Plenty of bugs have been fixed. Thank you to everyone who has used Anonymixer so far!

We try hard to make sure that you don't get your coins from a previous mix, but it can happen. We will continue to develop the software further to try to ensure that this doesn't happen.

Aside from the fact that we have many individual coins/UTXOs, two approaches we currently take are;

1. Conf-Guard

Any coin that comes into the Mixer, must have at least 18 confirmations and be suitably thawed prior to leaving the mixer in any subsequent trade.

This caters for a user that makes multiple mixes in quick succession. If a user sends a coin to the mixer, there is absolutely no way that coin is coming back out of the mixer for at least 3 hours.

2. Most recent coins go out last

We have many Wallets. The Wallet which received coins into it last has the least likelihood and priority of being used to send out coins in subsequent mixes.

This caters for a user performing another trade on the same day or the next.

Hi LoveUJack,

For what it's worth and without going into too much detail, the software architecture of Anonymixer assumes that such entities have infiltrated the public facing server and have had 100% root access from the very first minute.

The public facing server writes nothing to disk, with anything of importance temporarily stored in memory on a need to know basis.
To my current knowledge, even with root access, a third party would be unable to eavesdrop on HTTPS network traffic.

All Anonymixer source code, both server side and client side is compiled, obfuscated and mangled.

Even with this software design in place, we have taken great care in securing the public facing server from outside attackers, for instance the server only exposes port 443 (HTTPS) and has an SSL Labs Grade A Rating. All keys are encrypted and buried away within very large binary files.

In the event of a suspected security breach, or if we just lost the server completely - we could setup an alternative server from an alternative provider very quickly.

One thing to note, albeit highly unlikely, even with this security in place, these "entities" do what they like, legally or illegally, when and how they please. There is nothing stopping these entities changing NameServer entries of the WHOIS records or altering your chosen DNS server's records so that on trying to resolve Anonymixer.com, you are actually pointed to their own server, which in-effect could act as a MITM. Or, they could simply confiscate the domain entirely.

We recommend using Tor, our Onion address is http://anonymixerpolbpy.onion.

@LoveUJack: that's actually a very good question.

There are a couple of scenarios tough:

• the mixer owner can hire a dedicated server. In this setup he can encrypt the necessary filesystems . If his host decides to cooperate with a 3 letter agency, they'll have to boot the server from a boot image to reset the root password, and at this point they'll be faced with the encryption. So the mixers clients are safe-ish (I do believe 3 letter agencys have more resources to break the encryption and ways to track down the owner to force him to decrypt any encrypted filesystems.. but still..)
• if the owner of the mixer is renting a vps, there is some isolation, but the host can still access the container
• if the mixer is using shared hosting and his host cooperates with a 3 letter agency, the clients are royally screwed
• it's also possible the host isn't a us based company (best case scenario it's a bulletproof host in a safe country)

So, in the end: yes, the mixer can make other not-do-smart choices hosting-wise. However, we know (for a fact) that cloudflare hosts content in the us, so no matter which choised about hosting the mixer operator makes: cloudflare is unwise.
Yes, the hosting can be an attack vector, but it's not because you already have one attack vector it's ok to add an other one you can easily avoid....

I do need to clear something up: I'm not against cloudflare per se! Cloudflare is easy, cloudflare protects sites that have nothing to hide, cloudflare speeds up your site, cloudflare reduces bandwidth.
Cloudflare is great for blogs, small stores, forums,... But cloudflare is bad for mixers.

PS: I suspect cloudflare of nothing... I have never seen any proof they're leaking anything to le... However the mere fact they *could* leak data as sensitive as this makes me think that any mixer using cloudflare is bad at opsec

EDIT: After writing this post, i suddenly realised i forgot to add a major point: IF the mixer is legit, he should NOT be keeping logs... If the host would work together with LE and they seized the server (or VPS, or shared hosting), the only thing they *should* get are the currently running sessions... IF cloudflare would leak info, they would be able to give the complete content of every package ever exchanged between the mixer and their clients.

I have some question regarding this paranoia about Cloudflare. If you suspect Cloudflare for monitoring a mixer and leaking data to FBI/CIA/DOD, why would not you suspect the web hosting companies for the same?

For example, it is no secret that Anonymixer.com is hosted on Hostkey.com and Chipmixer.com is hosted by Choopa.com. So, how difficult is it for FBI/CIA/DOD to get data from these web hosts, if they can do the same for Cloudflare?

@Bill Gates... I'll try to answer your questions one by one... Maybe not in the correct order...

1) I looked into it, and you are right, cloudflare started offering unmetered ddos protection in their free plans in september 2017. Before that, I have heared interviews with (what i think was) their founder... At this point he clearly stated that people on free plans got free DDos protection as long as they didn't stress their network. If a member on a free plan caused a nuisense for them, said member would be kicked from their service... I still had this in the back of my mind, but apparently they changed their business practices ~3 years ago. I couldn't find any articles about their previous busines practices, i don't think they're proud about it right now either... And i don't even know if there were public statements about this in the past, they probably didn't want to advertise this "feature".
Paying cloudflare members always got DDos protection... at least AFAIK...
Cloudflare still kicks regularly DDos'ed services from their network from time to time, look at 8chan.

2) i'm clearly talking about people that use cloudflare's SSL certificate. But even if you have your own certificate AND want to use cloudflare as a CDN, you have to upload your private key (no password): https://support.cloudflare.com/hc/en-us/articles/200170466-Managing-Custom-SSL-certificates.
Why? Because if you want to use cloudflare as a CDN, your traffic passes cloudflare's servers, cloudflare decrypts said traffic and caches it. There is just no way around this. It's impossible for cloudflare to work as a CDN the way they do by caching replies without them decrypting your traffic (it would be possible for them if they chose a different approach to being a CDN).
You can use cloudflare to maintain your DNS records without using their proxy and use your own certificate tough... Or proxy certain subdomains (for example, move your static content to subdomain and cache it while not proxying your main site and using your own ssl certificate for the unproxyd subdomain)/ But that's not the same as their implementation of a CDN

3) thank you for meriting my thread... I spent a lot of time writing it

4) same answer as 2). You can use your own certificate, but you have to give them your key...
I'm aware that they have Keyless SSL, where you keep your private key on your own keyserver, but cloudflare still knows each session's symmetric key... They have to, otherwise they wouldn't have anything to cache. It's a moot point... The difference between giving them your private key and helping them get their hands on the session's symetric key is small... at least from the enduser's privacy point of view.

6)
https://www.google.com/search?q=ddos+mitigation+hardware
My server is behind DDos mitigation hardware. I work for a very big company and all our external servers are behind our own hardware... I wouldn't dream off going to my boss and telling him to use cloudflare. I'd probably be fired on the spot.

BTW: there are ways to get the ip of servers behind cloudflare... This is a reply to your previous post, not the one i'm writing answers for...
https://blog.detectify.com/2019/07/31/bypassing-cloudflare-waf-with-the-origin-server-ip-address/
https://securitytrails.com/blog/ip-address-behind-cloudflare
not 100% foolproof, but still..

Wrong. Cloudflare is a CDN and it does mitigate DDOS attacks. Read more about it here: https://www.cloudflare.com/ddos/. In fact, BitcoinTalk also uses Cloudflare for DDOS protection.


This depends on implementation. If the website owner is using HTTP then MITM is definitely possible. If HTTPS is used, where SSL is provided by CLoudflare, then also MITM is possible. But, if, HTTPS is used, but SSL is provided by hosting provider, then CLoudflare has no way to intercept. This helps to protect from DDOS as well as mitigate the risk of MITM.


Was not aware of this thread. It is a fantastic thread to be honest. I have merited whatever I had to this thread.


Wrong. Part 2: A https site using it's own certificate (aka, best case scenario) - this is the best case scenario when used in conjunction with Cloudflare, because Cloudflare mitigates the DDOS problem as well as hides the hosting IP from public eye.


Please enlighten the community with those superior ways to mitigate DDOS. BitcoinTalk may adopt those to get rid of Cloudflare as well.

It's the other way around...
A CDN is just a content delivery network. It won't protect you against DDOS attacks.

I do know one CDN that's giving away proxy functionality for free... And because they act as a proxy, they also mitigate DDOS attacks to a certain point (eventough their primary function is being a caching proxy). However, this CDN DOES act like a MITM. I stay away from any mixer that uses this CDN, since they'll decrypt any data exchanged between me and the mixer and they'll be able to store the unencrypted data in a US based server farm.

I've actually written a complete thread about this in the past:
https://bitcointalksearch.org/topic/mixers-using-cloudflares-ssl-certificates-5247838
please read and educate yourself before you push anybody towards cloudflare in the future... Cloudflare is fine for any service that isn't privacy-focussed... But not if you think your clients don't want their details in an FBI/CIA/DOD/... database. I, for  one, wouldn't care if the FBI knew i was buying new lightbulbs, so a lightbulbstore could use cloudflare.
On the other hand, i WOULD mind if the FBI knew i was mixing coins, or buying a subscription to a porn site, or if i bought a new hunting knife. So if one of these businesses would use cloudflare, i wouldn't touch them with a 20 foot pole.

What the OP is doing is the best possible scenario...

BTW: there are other, better, more superior ways of dealing with a DDOS attack. If you're running an online service, and you need privacy for your users, you should stay away from cloudflare...