Bitcoin Forum

The "accounts" feature (to replace "labels") is done for now:  listtransactions and gettransaction are implemented, and move, sendfrom, and getbalance <account> are enabled.

This should make implementing web services much easier; you can assign each customer their own 'account' and rely on bitcoin to keep track of exactly how many bitcoins they have, have it return a list of the customer's last N transactions, etc.

This is a minimal implementation on purpose-- for example, gettransaction doesn't return every possible bit of information you might want to know about a transaction, and will only return information for transactions in your own wallet.  We are trying to think ahead and not add features that will be broken or taken away when bitcoin supports running in a 'lightweight client' mode, without access to the entire bitcoin transaction history.

I've updated the API wiki page (http://www.bitcoin.org/wiki/doku.php?id=api) with the new methods.

This is great. However, I think accounts and labels are two separate needs. I'd like to share my own experience, in case it can help.

I'm currently working on a sort of "webservice", only via XMPP, not HTTP (a jabber-to-bitcoin gateway). It works much like myBitcoin: you let it manage a bitcoin address for you, and you send it commands (like "pay 150", sent to a JID representing a bitcoin address) to make it send the bitcoins wherever you want.

However:
 1. I'm allowing people to have more than one address.
 2. I'm letting people label each address.

This means I need to use the label as a label, and it also means I can't use it to store the account. So I'm solving this using an external database to store relationship between addresses and users.

I'm sharing this here because I think it's normal for a webservice to be willing to offer more than one address per person. If such a limitation exists, people won't use it, so having a notion of account with such a restriction seems pointless to me.

(My BTC 0.02.)

+1 agreed

-1, completely disagree here.

Label functionality should be handled at application level (specific application that is).

What if I wanted to tag my addresses instead of label them, and allow multiple tags for one address ?

No, definitely, that's the application responsibility, whatever the meta-data you want to associate to an address you shouldn't rely on the bitcoin client to handle it.

Accounts, on the other hand, provide with the very important functionality of enforcing a positive balance.
Of course, that should be enforced at the application level too.

I check for data integrity at the application level, but I still define referential integrity constraints at the database level, and I think it should be the same approach when interacting with a bitcoin client.

What happens to the existing label functionality? I have a webapp that uses a label to get an address then uses the address. Will this still work or will I have to change the app to use accounts?

You can continue to use accounts as labels, create an each-address-gets-one-label, and map addresses-->user in your database.

However, your application will be faster and simpler if you let bitcoin do the addresses-->user mapping (one account per user), and store address-->user-specified-label in your database.

The bitcoin 'getaddressesbyaccount' method will give you the addresses-->user relationship, and all the accounting becomes much easier (listtransactions gets you all the transactions associated with a particular user, etc).


The label methods still work, call the corresponding account methods (e.g. call setlabel <bitcoinaddress> and it calls setaccount), but are deprecated, so they don't show up in the help and will eventually be removed.

The only 'potentially breaking change' is the sendtoaddress function, which now returns a transaction id instead of the word 'sent'.

Fair enough. I started with the orthogonal approach because back then, the API was dealing with "labels", but indeed it will be a lot easier this way. Then each address's label, if any, will be an entry in the database. (Actually, I could even drop the whole label concept, since people can give each address a name in their Jabber roster. That's another topic though.)

Thanks for the thoughts.