Quote
What I could probably do is modify bitcoind to flag accounts/privkeys/addresses as "don't use" versus "only use";
We do want that functionality, mostly to make it so that users using the raw transaction api can mix it with regular wallet usage without stepping on themselves.
Quote
and then have the modified bitcoind only encrypt the data for those particular addresses.
This is very much incompatible with how encryption in Bitcoin works today. And I think we'd be unlikely to accept patches to change it to make that work.
Today there is a master key which is used to encrypt all the private keys, and the master key is encrypted with a KDF expanded passphrase from the user. This makes it possible to change the passphrase without rewriting all the private key material.
It's also important to note that bitcoin's account feature is __NOT__ multiple wallets, spending from any account can spend any coins, including ones that were previously paid to another account.
Quote
That way no one who managed to get a hold of the wallet could do anything without the account password, and even someone scouring a memory dump for info could do nothing without the account password, or at worst could only gather accounts one login at a time.
If you make use of a private key then someone going through memory could get a copy of it, end of story.
What you are asking for could be accomplished via the raw transaction API, but you'd end up having to implement all of the wallet functionality in your own code. It could also be accomplished through multi-wallet support, which is something that I think we want long term but isn't being directly worked on right now.
But I think what you actually want really involves multisig or at least client side signing... because without that a sever compromise still results in compromising at least the private keys that get used during the compromise.
