We have responded to your e-mail.

The trade was created 4th December. You sent a single small deposit and miscalculated on transaction fees and want it returned.

Transactions fees have been so high recently, at one point going above 400 sat/vb, that it would cost us the same amount in Transaction Fees, just to send this back to you.

As a good will gesture, we have extended and extended this trade for you. It remains open, if you send the remaining balance, it will complete as expected.

Hi Jerome,

Thanks for noticing, you're probably aware it's to prevent outside observers correlating amounts going in, with amounts going out. Had your trade included more than one output address, you'd be presented with one initial deposit address.

The clearnet site is now pretty much up all of the time and will be going forward, despite being under intense DDoS attack (even as we speak).

Since ChipMixer left, we were obliterated from so many types of attacks; DDoS, some kind of ping/icmp style attack causing CPU to overload and freeze including on boot, false "abuse" reports of the server IP performing port scans then getting canned by hosting provider, getting mail bombed with spam, it just goes on. We got kicked off so many hosts trying to deal with it all but never gave up - we'll never use Cloudflare, DDoS-Guard or any other service that can eavesdrop on traffic.

If the total outgoing BTC is higher than the Hot maximum, then it's a Cold Trade. Hot Trades are automatic, Cold Trades are signed off from a hardware wallet.

🎉🎉 Anonymixer is now 3 years old!!! 🎉🎉

In a market where mixers come and go (and exit scam), we're still here and we treat people the way we would like to be treated!

After 3 years, we're still here and committed to protecting your privacy.

Just to remind,

• Anonymixer is the only mixer that does not rely on CloudFlare, DDoS-Cloud or any other "man in the middle" traffic logging service
  
• Anonymixer is the only mixer with a SSL / TLS Grade A+ rating, the strongest encryption
  
• Anonymixer does not charge additional fees per Output Address. Just a low 1 - 2% fee + network fee, so no hidden surprises
  

The Anonymixer clearnet website was fine yesterday, but today is under another 100,000+ unique IP DDoS attack again, apologies for the inconvenience.

The clearnet site should be back up by the end of today is up, without help from Cloudflare, DDOS-Guard or any other third party service.

It would take just one secretive subpoena from US Government to force Cloudflare to silently collect all traffic for 12 out of 17 mixers on this list, eavesdropping and destroying privacy for their users and similarly little pressure from "International Partners" to force DDOS-Guard to do the same for the remaining 4.

UPDATE: Clearnet site is back up - hope the 100k+ strong botnet enjoys it

Thanks for pointing this out, LeGaulois! The anonymixer.org website is indeed a scam.

It's considered a tip and the trade goes through, as is. This can actually be a great way of avoiding change coming back to you from your deposits.

However, if you've made a mistake or sent way too much, we can arrange to get the excess deposit(s) returned to you - just send us an email.

The self-signed certificate which can be used to verify the authenticity of PDF Letters of Guarantee, expired yesterday.

For those who rely on this, please update and trust the New Certificate in the same way you did before,

Please see https://no-js.[banned mixer]/help/trade/trusting-pdf-signing-certificate

The new (Self Signed) Certificate is:

-----BEGIN CERTIFICATE-----
MIIB9TCCAZmgAwIBAgIEGR+vSjAMBggqhkjOPQQDAgUAMG8xEDAOBgNVBAYTB1Vu
a25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNV
BAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xEzARBgNVBAMTCkFub255bWl4
ZXIwHhcNMjIwNzE0MTQyODQ4WhcNMjUwNzEzMTQyODQ4WjBvMRAwDgYDVQQGEwdV
bmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYD
VQQKEwdVbmtub3duMRAwDgYDVQQLEwdVbmtub3duMRMwEQYDVQQDEwpBbm9ueW1p
eGVyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEISAOfDq4demVEDYb7d0LwjNZ
AF+PF7zzhmTRa52EsS3vKRJWpI+K2X6rGcX6M4NXb6FMlo9eWglyoXBrEDz7XqMh
MB8wHQYDVR0OBBYEFBd9YtbAIn2ptTvddxbtg4VKy7y7MAwGCCqGSM49BAMCBQAD
SAAwRQIhANEQqDh2S6yIQBNeR6b3Gb4++ALv1cBzD53Xg8otlP49AiBg8lf062S8
ywP6zX1XImTHqPd7oPjzDpck8mIDaeGQRQ==
-----END CERTIFICATE-----

Signed By: 1AnonyMix35XkzRusC7FAzwi9KKggnyg5b
Signature: H74RXq3+umK72KCFEvs9HcF9lgyCTXCvYjHAa55ZZi24Kxum1NbvKpywCulncyNX2zExKezqlgLUIMaKxtQDhig=

Yes the attack is over, the vulnerabilities are fixed and no it's unlikely to happen again.

It was an attack on the V3 network as a whole and was patched by the Tor devs.

If the same (or similar) attack did happen to come back and the V3 network was destroyed - our infrastructure would still be standing and operating.
We spent 2 weeks re-developing our internal architecture assuming that the attack on the Tor V3 network would persist indefinitely.

Tor is removing support for legacy V2 addresses. Tor V3 addresses provide better encryption algorithms and anonymity.

Anonymixer's primary Tor V3 Onion address is:
][banned mixer]

Please update any bookmarks which reference the old Tor V2 Address (anonymixerpolbpy.onion).

Also, Anonymixer will support Taproot addresses when the soft fork fully activates in November.

Quick head's up, before anyone's scammed, It looks like some one has attempted to create an ]Anonymixer copy (or scam clone), over at https://coinmixer.it/

Fortunately, it's not a great copy, with just 1 P2PKH deposit address and 1 output address, fixed mixing delays, no Onion URLs, no PDF, etc.

They were likely unable to re-use the JavaScript /help/faq#no-js]due to the protections in place and re-creating the No JS functionality was probably too time consuming.

I've boiled this down further, I think -- a more concise explanation, for reference:

• Alice wants to Pay Bob 0.5 BTC
• Alice sends 0.2 BTC to Deposit Address A, followed later by 0.3 BTC to Deposit Address B
• Coin Z (0.5 BTC), somewhere else, is sent to Bob and is entirely unconnected to Alice's deposits

More, and most importantly:

• Coin Z went through 200+ separate CoinJoins over a period of 6 months
• The Coin Alice Deposited at Address A, later on that day participates in a CoinJoin
• The Coin Alice Deposited at Address B, participates in a separate CoinJoin 2 days later
• Alice's Coins are CoinJoined 20 or even 200 times before they even make their way back out of the mixer

Please consider ]Anonymixer.

We use Native SegWit Bitcoin addresses (Starts with bc1**), which are ~44% cheaper for Transaction fees than legacy Bitcoin addresses (Starts with 1**). There's no minimum.

Exact costs are presented to you up front, before you go ahead, so there's no surprises.

Sending 2 Deposits isn't required, you can space out the time between deposit and coins sent out from the Mixer. Sending to multiple deposit addresses in the same Transaction also works and saves on fees.

Your Coins can not be traced back to you.

I lost all my Bitcoin in a boating accident.

I would probably write a Maker implementation, which ran interfaced directly between the rest of the AM Hot Wallet system and the Join Market Network, which essentially runs on auto-pilot*

I would also probably write a Taker implementation, which is kicked off on an Ad-Hoc Basis from existing GUI software I've written to manage everything, including performing Cold Signatures for Cold Trades. In this case I would be initiating a CoinJoin and Digitally Signing it off from a Hardware Wallet*


I have had a think about what you said some more, over a long walk. I still think there is merit to this and that I wouldn't be cutting into the branch I'm sitting on, the key point here is that UTXOs are not only circulated by continual CoinJoining but also through conventional mixing, which is what I am already doing. Essentially your deposits are switched out, later, after being CoinJoined, so this hypothetical branch we speak of 20 CoinJoins down the line - I don't think would actually be a likely scenario.

* Exact details of the implementation, precisely, exactly how this would work, including ensuring that I didn't co-spend (or even present to the network) more than one of your deposit inputs in a CoinJoin that you had deposited in a trade, is a detail and a problem that I would solve, which is part of actually doing it and takes time - the kind of detail that needs to be solved later - if I decided to actually go ahead and do that.

For the moment I am only trying to gauge people's feelings on this. You have a JoinMarket node running permanently, but others do not.

I am specifically trying to gauge how people feel about receiving a Coin that has been "CoinJoined" VS a Coin that may or may not have a directly "questionable" lineage.

Just to point out the absolutely obvious, in-case anyone was wondering. A Coin that is Deposited in a Trade would never be CoinJoined then sent back out to the user ---- that would be fantastically rubbish.

I am going to continue to think and sleep on it. Stuff appears to happen in sleep and sleep-like states, for me at least anyway.

The Maker and Taker code would be written from scratch. However, still interfacing and communicating with same IRC channels as the regular JoinMarket Python software. Transactions produced would still appear as if they had been produced from the Python software. I would not be running on an entirely different network, but the internals and decision making in terms of which UTXOs were selected and which Output Addresses I chose would be up to my own software.


Strictly speaking, 1 CoinJoin away, I think you're definitely right. Sorry for that, but at what point does this change? I am not sure this is "absolute" as it dilutes to some extent with time?

If you sent Coins to an Entity which then performed 20 CoinJoins in a row over time (each CJ with other JM parties, each time). If you received Coins back from that later, 20 CoinJoins down the line, are these still "Your Coins"?

Becoming a Maker, I would always provide strong liquidity, forever, which is built up from a wide variety of UTXOs which continually refreshes naturally based on regular mixing, let alone JoinMarket participation.

As far as anonynimity is concerned, I am unsure of what the issue would be? I would need to keep track of which UTXOs had been presented in combination with others, which is not a huge task, I think the JoinMarket software already does this, however I would be writing the Maker implementation code from scratch (I don't code with Python) and later a Taker implementation for on-demand ad-hoc Cold purposes (i.e. Initiating a JM CoinJoin direct from Cold Storage to Cold Storage). I wouldn't have 4 "mixing depths", I would do my own entirely separate thing picking UTXOs and Output Addresses accordingly based on my own requirements.


It does have the same problem, in terms of making coins produced from the Mixer look like they've been produced from a CoinJoin, which is why this is a discussion only for the moment.

There are a key couple of problems it does solve:

• Chain Analysis companies, would find it impossible to keep track of Mixer wallets / clusters. no matter how much they used it, or how much dust attacks they sent.
• Coins sent out from the Mixer could never be tainted with past activity, other than endless CoinJoins
• Coins sent to the Mixer could never be associated with the original user, due to the endless CoinJoins

If I ensured that all deposits must first be CoinJoined prior to going out again, that's never going to happen. Just saying.

This makes sense. In the 1 => 1 transaction you could include an OP_RETURN Output with a message stating this. An example:

https://blockchair.com/bitcoin/transaction/1de99d383743158acfc2d2a21231c226df23c24c1ba4aa1059addcf5e1b348b5

Some-one may be prepared to pay money for that.

The thing is, once you shift those coins, even a Transaction of 1 => 1 the coins are now no longer "aged".

To hand over "private keys" to the buyer, the unfortunate part about this is that the seller may still posses a copy of the keys and can spend from those inputs in the future.

There is nothing stopping you running a JoinMarket maker node, providing you have the technical capability to do this. It also means you leaving your Bitcoin funds in hot wallets connected to the internet at all times. In my experience, despite offering strong liquidity with 0 fees as a Maker, JoinMarket takers can not come to initiate a CoinJoin until quite some time later, it may be 24 hours, it may be 4+ days.

Wasabi is not instant, they join once an hour providing something doesn't go wrong which it often does, you need a minimum of around 0.1 BTC to participate ($5,600), whilst also leaving you with plenty of "toxic waste", which you are urged to either throw away or donate to others to then co-spend on your behalf [1]. Given the high and increasing price of Bitcoin, this is very wasteful indeed. They also put incredibly low fees on the CoinJoins in my experience, with funds not confirming for 1 or 2 weeks.

With CoinJoins you do not jump the transaction graph. Large CoinJoins are impressive things on the outset, but your funds can be traced, it's difficult, but overtime your anonymity set degrades and certainly in Wasabi's case questions remain over how much they "Wasabi" join in with their own coins, leaving room for coercion and sybil attacks from authorities.

The value of a Bitcoin Mixer which did this, would be offering a user the ability to easily "dip in" to this forever spinning pool, which could have been spinning for the last 6 months continually. The user would get the best of both worlds so to speak, they would jump the transaction graph, whilst receiving coins which would always be anonymized from endless CoinJoins. Coins which were sent to the Mixer would also be added to this forever spinning CoinJoin pool. I think paying 1.5% to a service to provide this, on demand at 1 minutes notice, including getting coins Confirmed quickly is probably a fair price to pay.

[1] https://[banned mixer]/help/wasabi-change-coins

There are pros and cons of using Bitcoin Mixers vs multi-participant CoinJoins.

On a 10,000 foot level, the basic differences are:

• Bitcoin Mixers allow you to jump the Transaction Graph, but rely on users trusting third parties to do this well, with no logs
• CoinJoins give a degree of anonymity on a Join by Join basis, where the anonymity set degrades over time, however there is no requirement to trust third parties
• Unless a Bitcoin Mixer co-spends many inputs in 1 Tx, their wallet(s) / cluster(s) are unlikely to be picked up by chain analysis firms
• All CoinJoins are easily identified, to the point where it's even known exactly which implementation has been used

Coin discrimination is real. Exchanges and KYC services are more frequently freezing users funds based on identifying that the user performs CoinJoins, pending further KYC checks and demand the user ceases further CoinJoin activity (Ironically, the exchanges refer to it as coin-mixing).

Using *some* Bitcoin Mixers on the other hand, the coin sent from a mixer and it's lineage, can in some cases be questionable in nature.

I have been thinking about an alternative hybrid approach, which I want to propose here and gather people's thoughts on this:

• This approach involves a centralized Bitcoin Mixer behind the scenes, continually participating in CoinJoins 24/7
• The Bitcoin Mixer would act as a JoinMarket "Market Maker". Charging 0 fees where "Market Takers" pay the Transaction Fees for each CoinJoin
• It would be impossible to track the Bitcoin Mixer's wallets/clusters, as they would be forever moving targets, not only with normal client funds but also continual CoinJoins

The issue that arises from this is that Coins sent out from the Bitcoin Mixer would then look like they had recently participated in a JoinMarket CoinJoin (because they have), as opposed to simply looking like a regular coin which had been sent from another Bitcoin User.