Obviously nobody knows.  Any one of the mixers could be operated by a government.  Or a government might have learned their private SSL keys and be reading all of the traffic.

Clearly, using two mixers gives you a better chance of actually escaping logs.  It also increases your chance of getting scammed.

A subverted popular mixer would be a valuable intelligence asset to law enforcement, and they would avoid using the information in a way that could reveal its source.

Any mixer that has a reputation and traffic has a substantial incentive to stay in business and keep collecting fees, rather than pulling an exit scam.  Beware a new mixer with low fees.

All of the mixers are frequently phished.  Check very carefully to find the correct URL.

The mixers always sign a document specifying the input and output addresses.  Be sure to save the document and check the signature.  After the mixing is completed, you want to destroy the document.

After paying the fee to isolate your input and output addresses, don't watch both input and output using a block explorer or a wallet such as Electrum that queries the internet to find out about the addresses.  Supposedly these services don't keep logs, but they could. Either use a node such as the Satoshi client which has a private copy of the whole blockchain, or use Electrum via Tor to watch only one address.  To start watching a second address, delete the first from the wallet, exit Electrum, delete all of its data (or at least ~/.electrum/wallets/default_wallet), tell Tor to open a new identity, and only then restart Electrum and enter the next address.

Thank you for considering it, and for the advice about using the API for long delays.  BTW if you arrive on your site with javascript disabled, it's not obvious how to proceed.

Thanks for the reply. 

Adequate security is defined in terms of your threat model.  I'm talking about users who expect that significant compute power (thousands of dollars worth) will be applied to the blockchain in order to follow their transactions.  A few simple optional adjustments to your service could increase the cost of following the transactions significantly, or even make it actually impossible (given absence of other security mistakes by the user).

I mentioned electrum because your customers might use it or a block explorer to watch the address they sent coin to, and also at the same time all of their receiving addresses.  If the threat model assumes those servers might be compromised, then the action of watching all addresses at once links the addresses.  Thus, customers should be warned that their coin could be followed by sufficiently powerful adversaries unless they run their own full bitcoin node to watch the addresses.

One point is pretty unacceptable:  if you specify the same percentage for two outputs, then both outputs are exactly the same.  There aren't enough transactions per day on the blockchain to hide this.  Also, once the duplicate amounts are noticed, the other output transactions will be identifiable because there is no randomness applied after the fee is deducted, and because there are no fractional percents allowed.

But using random assignments of the per output fee is unnecessary.  All you need is to let the users specify parts per ten thousand instead of parts per hundred.  (That is, allow two decimals in the percentage:  x.yz%)

And while you are at it, you should allow one decimal in the hour, which is to say, delays are specified in units of six minutes instead of sixty minutes.  And delays up to 48 hours.

The default percentages and delays should be assigned randomly.  You should have text boxes to enter exact percentages or delays, and a checkbox to lock the value.

To make it easier to make specific payment amounts, you could provide a text box for the expected input total, and display output amounts beside the percentage.

Finally, you should support browers with disabled javascript.  There have been zero-day vulnerabilities in javascript.  This page would just have text boxes to type in the desired percents and delays, and a "proceed" button that displays a confirmation page, with any errors pointed out.

For one thing, the electrum wallet software sends all of the addresses in a wallet to the same server.  Some servers try or claim to not keep logs.  Others don't even say.  Tails comes with electrum.  :-(  So if your threat model calls for disconnection of output addresses, you better be careful where you get balance information.

And if you put the input and output bitmixer addresses into the same wallet (or even separate wallet files), your friendly electrum server, or block explorer, can associate the input and output addresses.

I'd say the only safe way to follow balances of addresses you want to keep completely isolated from one another is to run your own full bitcoin node and keep your watching wallet there.  But that's not very easy to do while using tails.

A second way that output addresses can be associated is by searching for other transactions where the amount of satoshis have common factors.  This happens because bitmixer first subtracts the random fee, and only afterward divides the outputs, and because the division coefficients have to be multiples of 0.01 (1%).

So I sent in 1**,***,*** satoshis, with fee 0.****% + 0.0005 BTC / output * 8 outputs, and  received  1**,***,***.  So the fee totaled 1,***,***, or 1,***,***+400,000, as it should have.  Each output of x% was exactly (input - fee) * x% - 50,000.

Two outputs were specified as 10%, and both received exactly 12,***,*** satoshis.  I seriously doubt there were many other transactions that day with that exact amount.  Another pair were 11%, and both received exactly 14,***,***.

When multiple output addresses are given, the 50,000 satoshi per address fee should be randomly divided among them, instead of deducting exactly 50,000 from each total.

The transactions did not all arrive at the same number of minutes after the hour, but they all arrived in the same half hour (5 minutes after the hour to 38 after, and six of them arrived between 11 after and 23 after).

Avoid unnecessary trust.  You don't need to derive other private keys from the ...Eiyyp... key, making all of your private keys vulnerable to a single leak.  If I were you, I'd make fixing that a top priority.

I found it was not easy to find out how to verify signatures using a bitcoin wallet.  The documentation is much less widespread.  And it involves three separate copy and paste steps.

Regarding gpg, using tails (the amnesic incognito live system, tails.boum.org), booted from USB stick with encrypted persistent storage (so you import keys once), checking a gpg signature is done by copying the document to clipboard, clicking on the icon in the upper right that looks like a good old brown masonite and steel clipboard and selecting "Decrypt/Verify clipboard".  (When the clipboard contains a signed or encrypted document, the clipboard icon has a red hexagon in the center).  A dialog comes up with results.  It gives the key ID that is needed (or was used) to verify the document.

If the key is missing, select "manage keys" from that clipboard icon menu.  A window comes up titled Passwords and Keys.  Select "Find remote keys" from the "Remote" menu, and paste the key ID into the dialog. Or, if the keys are available on the https website, you can download them from there and select Import from the File menu of the Passwords and Keys window.

How do you know the private key of address 1BitmixerEiyyp3eTLaCpgBbhYERs48qza has not leaked?  Hint:  you don't.  You obviously have to keep it online to sign letters of guarantee.  The more days it remains online, the more likely it has somehow leaked.

I can see it's not all that important to users (a thief could forge a letter of guarantee and embarass you here), but it just gives the impression of sloppiness.

You would probably want to keep the current bitmixer API and webpages unchanged, but add a link to a new version which fixes this and maybe other problems.

You should generate a new 1BitmixerNew... address on an offline machine, certify it as unexpiring with the old key, use it to sign a large quantity of keys (each document specifying the date(s) the key is valid), and immediately destroy the 1BitmixerNew... private key.  The signed keys should be placed on some physical medium and stored in a safe deposit box.

Then you bring out say a week's worth of keys at a time, and import the next key to the server as needed.

The revised letter of guarantee includes the certificate giving the 1BitmixerNew... key signed by the 1BitmixerEiyyp... key, the currently valid guarantee signing key signed by the 1BitmixerNew... key, and the guarantee signed by the guarantee signing key.

And maybe you could consider using gpg keys instead or in addition?  This stuff is fairly well automated in gpg.
You could just run the letter of guarantee through gpg, appending a signature made with the currently valid signing key.  Also, you could provide a gpg keyring text document giving say a year's worth of document signing keys and the keysigning gpg key.  This document could be signed by the 1BitmixerEiyyp... and the 1BitmixerNew... bitcoin keys.