Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/513f8059232f8288a4798ac62f1a9982924ab716 for binaries and test log.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/cb944ad47e8ce752376783f0104c5ae20b2c88fb for binaries and test log.

How do you control whether the Bitcoin client includes the address in balances or not? I think it would be helpful to be able to watch addresses without considering them your own.

Right, so there are two solutions I see here:

1. Ignore nonspendable outputs from balance calculations for sending transactions and add an option to the getbalance method (or add another API call) to distinguish between total balance and spendable balance.

2. Add support for multiple wallets and require a wallet to either be 100% spendable or 100% unspendable.

It will probably also be necessary to add another field to the returned JSON for certain calls that states whether the addresses are spendable or not.

I would prefer to have a completely separate structure for verification/tracking/ultrapruning of transactions and have the wallet just deal with private key storage and transaction signing. But that would require too many changes to get it integrated quickly. I think either of these two solutions is a reasonable compromise for now, the second one perhaps being more powerful and simpler from a usage perspective.

Probably option #1 is best, so there can be "this is mine, and I have the private key somewhere else (so prompt me for it when I need it)" too

Not just "prompt me" but we should actually store some kind of token which is returned. Unfortunately pretty much none of our private key using APIs are setup in a way that would reasonably work with them returning 'need private key with token foo'.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/f92db3b58692820e1cd72d2beaa653ba225f09ab for binaries and test log.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/fc05746a0bfce4de4686d8bb0880082e9cf2b7b5 for binaries and test log.

I think a feature to have a number of balances would be ideal, and that way the user can choose which addresses to includes in which groups of balances. Either this, or just have a default separate balance for the offline (i.e. public only) addresses (well, two, one for unconfirmed, and one for confirmed).

I think that would make things too complex for users. Ideally, we'd just have multiwallet support and watch-only wallets, without per-address spendability.

As to not break compatibility with the existing RPC calls, I'm thinking we can have a main wallet which is always used as the default wallet. If the user wants to use a different wallet, the name of the wallet would have to be specified in the call. Unfortunately, it doesn't look like we can use many of the existing RPC calls (sendfrom, sendmany,sendtoaddress, etc...) since they all have optional parameters already and it would be awkward to just tack on the wallet name parameter at the end. Also, walletpassphrase is problematic as it is not stateless. So it looks like we need a whole separate set of calls which require a wallet name and passphrase (if the wallet is encrypted).

For instance,

walletsendtoaddress <walletname> <passphrase> <bitcoinaddress> <amount> [comment] [comment-to]

This is one of the unfortunate things about relying on parameter order rather than key-value pairs.