Multiple Wallets, one computer (multiple accounts)

[Gavin Andresen]

If you're running something like mybitcoin or mtgox or any other site that lets customers keep bitcoins in accounts, then one-customer-per-bitcoin-process isn't at all practical.  To start with, every bitcoin process has a complete copy of the block chain...

[1714006817]

1714006817

[1714006817]

1714006817

[1714006817]

1714006817

[grondilu]

If you're running something like mybitcoin or mtgox or any other site that lets customers keep bitcoins in accounts, then one-customer-per-bitcoin-process isn't at all practical.  To start with, every bitcoin process has a complete copy of the block chain...

Indeed.  I hadn't thought about this.  I guess there is also the problem of port mapping.

[ByteCoin]

If you're running something like mybitcoin or mtgox or any other site that lets customers keep bitcoins in accounts, then one-customer-per-bitcoin-process isn't at all practical.  To start with, every bitcoin process has a complete copy of the block chain...

This would be one reason for splitting the bitcoin client functionality into two orthogonal parts.
One part would maintain the block chain, verify incoming transactions from the network and provide the interface for obtaining useful information from the block chain. It would neither contain nor have access to any private data. It would have large data files which need never be backed up but re-downloaded if lost. This would be the "server".

The other part would run the UI and allow the user to generate transactions, maintain the user's wallet(s), show the user's balance, incoming and outgoing transactions. It would contain the minimum of information that is also encoded in the block chain and the files would be small and easily backed up. This would be the "client"

Possibly hash generation could be a third independent process which is optimised for the individual CPU and other hardware. It requires no storage and just communicates with the server portion. Possibly the server portion could come with the default hash generator built in but most users with serious hardware like CUDA would run specialized hash generators using the interface on the server.

ByteCoin

[jgarzik]

If you're running something like mybitcoin or mtgox or any other site that lets customers keep bitcoins in accounts, then one-customer-per-bitcoin-process isn't at all practical.  To start with, every bitcoin process has a complete copy of the block chain...

100% agreed, but that is not the only "multiple wallet" (multiple instance) use case.  This account system sounds useful, but it should not be used as a justification for avoiding the addition of "-bindport" feature, to change the default 8333 port.

[nelisky]

Yeah, I'm already running multiple processes, but not one per client, rather one per service. It's not practical at all, keeping the ports under control, had to create bitcoind wrappers for each one of these or it was total hell.

I just don't see this scaling to one process per client, even if you don't have a huge number of clients.

[Gavin Andresen]

An impromptu brainstorm this morning in IRC chat (thanks everybody!) helped me think through a few issues for an "accounts" API.

The big idea:

Replace the JSON-RPC "label" API with the notion of "accounts".

What is broken about the current API?
 + you can't get a list of all transactions that make up an account's balance
 + if your bitcoin service has the notion of maintaining a balance for multiple
   customers then you end up mirroring information stored in the bitcoin wallet database.
   Mirroring is a problem because if the connection between your service and bitcoin
   fails at the wrong time (e.g. between sending a "sendtoaddress" and getting
   back "sent") your database can be out of sync with the bitcoin reality.

Problems this proposal does NOT tackle:
 + multiple "wallets" for GUI bitcoin users
 + improving anonymity by keeping "coins" from different people in different "wallets"
 + "push" notifications from bitcoin when coins are received (or blocks generated)

NEW METHODS:
------------
getaccountaddress <account>
move <fromaccount> <toaccount> <amount>
sendfrom <account> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]
listtransactions <account> [minconf=1] [count=10] [start=0]

CHANGES TO EXISTING METHODS:
----------------------------
getbalance [account] [minconf=1]

listreceivedbyaddress:
  return "account" instead of "label" in JSON-RPC result

sendtoaddress:
  same API, but debits accounts as described below

METHODS RENAMED:
----------------
setlabel --> setaccount
getlabel --> getaccountfromaddress
getaddressesbylabel -> getaddressesbyaccount
getreceivedbylabel -> getreceivedbyaccount
listreceivedbylabel -> listreceivedbyaccount
  ... returns "account" instead of "label" in result


METHODS REMOVED (deprecated):
-----------------------------
setlabel


NOTES:
------

All existing routines would continue to be supported for a while (e.g. listreceivedbylabel would be kept as a synonym for listreceivedbyaccount, and would return both "account" and "label" in the JSON result).

Coins going into or out of the wallet that don't have an associated account will be associated with a default account (named the empty string: ""). So sum(account balances) will always equal server account balance.

Generated coins will be assigned to the default account when they mature.

sendtoaddress, and the GUI "send" button, will debit accounts starting with the default account (if it has a non-zero balance) and continuing in alphabetical (ascii) order.the default address, which will be allowed to go negative.

None of these changes will be visible in the graphical user interface. These changes are for people running bitcoind to support bitcoin-related services, not for end-users.

It would be nice to support transactions by batching up several commmands and ensuring that they either all succeed or all fail.  But: this should be useful even without that feature.  The cleanest way of doing that is JSON-RPC-2.0 "batch send", and that all can come in a later version.

Why remove setlabel?  Because it is not clear what "setaccount <bitcoinaddrress>" means for old transactions that were received on that address-- do they remain credited to the old account (confusing!) or does history get rewritten so they are credited to the new account (your accountant/auditor will surely protest!).

UPDATE: svn rev 188 implements most of this (all but gettransactions).  And due to the disaster recovery scenario described below, 'setlabel' stays as 'setaccount'.

[jgarzik]

Comments:

• Very nice, though this makes using at least one account mandatory?  If yes, I suppose we can create a default 'master' account, just like git creates a 'master' branch by convention.
• I found it useful to label individual transactions, and will continue to find that useful even when using multiple accounts.  Labels remain useful as an ad hoc tx grouping mechanism (use case A) or an easy way to associate a user-generated (website-generated) unique transaction id with a bitcoin address (use case B)

[Gavin Andresen]

RE: one mandatory account:  yes, the empty-string-named-account will be the "master" account.

RE: existing use cases:  you should be able to do everything you can do now... EXCEPT for change the label of bitcoin address after it is created.  Although associating a unique transaction ID to a bitcoin address seems like the wrong thing to do (since the same bitcoin address might be re-used for multiple transactions; your application might not allow that, but the addresses are publicly available in the block chain and you might be opening yourself up to unpleasant hacks if you don't consider what should happen if an old bitcoin address that you THOUGHT would be used only once receives a few bit-pennies....)

This morning I thought through what might happen in case of a disaster and a service using accounts had to restore from a wallet backup and some other, alternative source of transaction history (maybe application-specific transaction logs sent to an offsite logging server).

Assuming your backup is recent enough for your keypoolsize, no bitcoins will be lost, but account balances will be wrong because any "move", "sendfrom", and associate-bitcoin-address-with-account actions will be lost.

I've tweaked the proposed API to make recovery easier; I'm still thinking about "setlabel" -- in the recovery case, you definitely DO want to be able to re-associate bitcoin addresses with accounts...

[Alex Beckenham]

Really old thread, but I couldn't find this discussed elsewhere...

What I am finding is that simply having 'accounts' isn't actually detailed enough and I'd love to be able to have subaccounts and subsubaccounts, etc.

Example:

[Australia]
   [Australian Web Site #1]
       [Bruce]
       [Kylie]
   [Australian Web Site #2]
       [Jack]
       [Nicole]
[New Zealand]
    [Kiwi Site #1]        
    [Kiwi Site #2]


Reason being that I'd like to know Bruce's balance for example, but the best I can do is find out the total balance of 'Australia'.

Currently to get Bruce's balance, I have to check his address with getreceivedbyaddress, and then keep track of any outgoing funds from this customer using other means such as SQL.