That system is probably very secure against an attacking fourth party (meaning someone other than the sender, recipient, or mix node) but I think it's more complicated than it really needs to be, for most use cases. It also has a weakness: M knows every detail about the transaction, including the sender and final recipient (and in my opinion the biggest challenge for this type of mixnet is untrustworthy mix nodes). However most of what you describe could be done within the framework I described in the PDF, if the user wanted to be that paranoid. M would not randomize anything, rather A_x's client would specify each transaction to be made, including sizes and delays, and could choose to route the transactions through multiple mix nodes. (Technically it's not a mixnet if there's only a single intermediate node. )


That's a very interesting suggestion. I think I need to learn more about exactly how coins are represented in the block chain, because I was under the impression this wouldn't work because no matter how many accounts a coin passed through, it would always be traceable through the chain back to every account it ever 'belonged' to.

So if I get a payment for 100 bitcoins composed of 20 smaller balances from 20 different accounts, and I trace those coins back and find that 1 week ago they all belonged to a single account, it's likely that the coins were passed through a "send to self" mix and the account from 1 week ago belongs to the same user who just sent me this payment. (Another way to say that would be, it's very unlikely that a user received a payment for (at least) 100 coins, then paid it out in 20 separate transactions to 20 different individuals who passed those coins through another series of transactions that coincidentally finally ended with accounts controlled by a single individual who made a payment of those coins to me. That's a slightly oversimplified example but still a realistic one I think.)