Multiple Wallets, one computer (multiple accounts)

+1

Nope, I really need it on a per-receiving address so that it is easy to directly track the balances from customers paying me. 

I guess one way to do this would be use the -datadir=<dir>  command line arg to specify a data directory (other than the default "$(HOME)/.bitcoin/"). You would only run the client on one directory at a time. (Note the directory is relative to the current directory for the SERVER bitcoind. Its safest to specify a fully qualified directory starting at the root.) Also of course the client does not need to be running  on any specific directory nor running at all to receive payments to addresses in any/all of the wallets.

Can you just create a new windows user and log in with that user?  Bitcoin creates a directory per windows user, I think.

I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,
free from his dictatorship and tyranny. That is solely my own opinion.

For the techical issue discussed: It is clear, that the "node" instance, that holds the blocks database, connects to the network,
exchanges data with peers and with users, is architecturally independent from the "wallet" instance(s).
Wallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.

So it is feasible to have "block chain" daemon, that will cache block database on disk and may also act as an intermediary
between the local users and "the network", so it will have no secret keys at all, no sensitive information.
And the local "wallets" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no "bind to port 8XXX" issue.
They will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.
And so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like "getreceivedbyaddr" does now.

Generation should happen at admin's local wallet, not at the networking node. That means "wallets" will be permitted to publish not only transactions, but solved blocks too.

For current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.
So the only hope is the alternative implementations, that aren't possible without the standard.

The "label" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.

If the API was extended as I describe below, would it solve the same problems as having multiple wallets?

Proposal:

+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
  (change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
  (returns array of [ "address" : "bcaddresssentto", "amount" : x.yz, "confirmations": n ])

Each customer "account" would be a bitcoin <label>.  Account handling would look like:

Create account / create new address for account:
  getnewaddress [account_id_label]
   ... tell user "fund your account by sending coins to {the address returned}"

Customer withdraws/spends:
  sendfrom [account_id_label] [address] [amount]
   (FAILS if balance for that account too low)

Show customer their balance:
  getbalance [account_id_label]

Show customer their transactions in/out
  listreceivedbylabel [account_id_label]
  listsentbylabel [account_id_label]

---------

Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer.  At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.

Separate "accounts" (addresses with labels) to accumulate Jackpots is the right idea.  Users buy tickets, bitcoins are moved to the appropriate Jackpot account.  When a Jackpot is won, transactions flow out of its account back to whoever won.

I have the beginning of something like this.  It's mostly like what Gavin described.

Some more rpc interface:

move <fromaccount> <toaccount> <amount>
   Move from one internal account to another.  I think blank account name ("") will be your default account.  If you sell something to a user, you could do move "theiraccount" "" 123.45.
   Is "move" the best name for this?  I shied away from "transfer" because that sounds too close to sending a transaction.

I'm thinking a new function getaccountaddress instead of overloading getnewaddress:

getaccountaddress <account>
   Gives you an address allocated from getnewaddress <account>.  It'll keep giving the same address until something is received on the address, then it allocates a new address.  (It automatically does what the sample code I posted some time ago did)

Would these commands make it possible in simple cases to implement your website without needing a database of your own?

use -datadir and change the port on the source code and then use a different dir and port for every bitcoin instance