Have you considered throwing a message queue, like RabbitMQ, up in front of bitcoind and then using worker processes to perform the operations? You'd keep two sets of books for your internal balance movements, one in the database and the other in bitcoind, and the workers would synchronize the two. Transactions involving bitcoind are sent to a queue and the workers could process the tasks at whatever priority is associated with the task. (eg, a withdrawl or a balance check could be given higher priority than an internal move command to change balances internally between accounts -- the database would already 'know' and bitcoind would be playing catch up).
I have considered this. I haven't completely rejected it, but there are several concurrency issues around it that could be tricky to address.
I'm slowly moving down the path away from using bitcoind for balance tracking. I'll have to parallel the balance tracking in the db while coding it all up, then run with overlap for a while, (making sure balances stay in sync) then finally I'll be able to pull all of the balance related stuff out of bitcoind. At that point I can shrink the wallet by extracting all of the private keys and importing them into a new wallet. From there on out bitcoind would be purely for deposit/withdrawal processing.
I expect this process to take a couple of weeks.
It's all manageable. I just hate that it means it will be a while before I get to do other fun stuff.
If I understand things correctly, the wallet itself is still BerkleyDB?
The sad thing is that if I understood C++ better this is probably easily fixable. All you have to do is store the users balance in a single place every time their balance is altered. You'd have to store it like 7 times, one for 0 confs, 1 conf, 2 conf, .... etc up to 6 confs, at which point you could revert to the slower method of incrementing through all the transactions. But even storing each users balance 7 times in a single place on each transaction would be way lighter than iterating through the entire transaction stack on an account to find the balance. At least with any kind of regular getbalance traffic. I'd setup a bounty for it, but I want to get away from BerkeleyDB entirely anyway so that I can get to a db stack with real-time replication.
Something tells me though that if it doesn't invalidate it the first time around, it may be open to replay attacks?
