Sorry for the wait! Just the JS version working with FoxMixer: https://github.com/teran-mckinney/doublemixer-js

Haven't checked it for browser compatibility. I hope this isn't too late and that it still helps.

That's pretty cool. I honestly haven't tested it, it's just prototype code. I can work on it and bit more and see.

Generally, my JS is geared towards the latest browsers. I don't bother writing anything for IE 7 compatibility, etc. But honestly if you have an in-browser Bitcoin wallet, they probably should be running latest versions anyways.

I think this is a great idea, let me know if you implement it.

Thanks for your reply!

Both the CLI and browser versions are client side only and don't rely on anything other than the existing mixing services.

Very rudimentary, only one backend is working. Most mixers don't add CORS headers and I haven't pursued having them add it a whole lot let yet.

https://github.com/teran-mckinney/doublemixer-js

Yeah, definitely possible to go to an intermediate address. I've used this setup a few times and never had an issue but have been aware of it as well. IMO: the mixer needs to honor their guarantees and if they don't, you can go after them with that. But you're right, if a payment is way too late, it doesn't work out. I've tried to set the delays to be pretty conservative to help with that.

What I like is that how it is, it's one shot. No polling, etc. Super simple, little to break on the client's side. No actual coin handling there. Intermediate step could be done with WalkingLiberty. It would add another "interaction" that might help track users at a network level, but if using Tor, should be fine.

If you really wanted to do that now, after installing doublemixer you'll get `foxmixer`, `bitmix`, and `privcoin`. You can mix with one of those into a `walkingliberty` wallet, then mix out to where you really want to go. Personally, as I've yet to have a problem I'm not too concerned yet. If moving a lot of money it would be more of a concern but again, haven't seen any issues yet.

I would advise against doing this.

Both mixing services are only guaranteeing the address will be valid for a limited amount of time. If there is a problem/delay with the 1st mixing service that causes the transaction to confirm after the cutoff time for the 2nd mixing service, or if multiple transactions are sent from the first mixing service with the last one being after the cutoff, then the second mixing service may not send you your money. This would be a real problem because some mixing services periodically delete their private keys associated with zero balance addresses in order to protect privacy of their users in case a government agency finds their servers.