Bitcoin Forum

How do you feel about bitcoind's accounts? Do you always use them? Never? Are there any cases where you'd advise for or against their use?

/I'm not making any statement about accounts with this poll, just wondering if people recommend them to new developers that wish to use bitcoind.

it is missing a "they suck!!! kill them before they lay eggs!!" vote.

I think there should be some special notes added to the API documentation (or at least a link to something) to describe clearly what Bitcoin "accounts" actually are because much of the negative views about them is due to not understanding them correctly (such as thinking they are the same as "coin control").

THEY CAN HAVE NEGATIVE BALANCES!!! feature? bug?

Am not aware of this feature/bug as after realising that accounts were not suitable for what I was looking for (which was really coin control) I stopped playing with them.

Actually now that I think about it this would make perfect sense as the "account" is just a label you put onto a tx. So if you send and you had never received with an address labelled as an account then of course the balance would be negative.

I guess it really just says more about the unintuitive nature of the implementation.

what do you mean by coin control?

Intuitively, one might think that sendfrom [account] [destination] [amount] would send from the address labelled with the account.  It does something else that I don't really understand instead.

There is a patch/branch for Bitcoin that enables you to nominate which addresses to send BTC from (normally you have no control over this).

In the next release (0.7) there will be a new raw transaction API which will enable you to do the same (and actually more as you will have complete control over the transaction with it).

What it does is basically label the tx with the account name (it actually doesn't have anything to do with which addresses are picked to send from).

Thanks, I would have named that sendas though.

Good call - I think naming the command sendfrom is what has confused people about its behaviour.

I have (unsuccessfully) tried to use them, but I am terribly comfortable with them.

I think the concept of accounts is probably better left to accounting software and don't really fit into the scope of what the bitcoind should be doing.  Bitcoind is not (and does/should pretend to be) an accounting program.

If it were up to me the developers should just cut them out and concentrate on more important things, perhaps extending the [comment] [comment-to] system to work with incoming transactions.

Actually they are nothing like accounting accounts which is exactly why I (and I assume some others) was confused by them in the first place.

The idea of a Bitcoin "account" is to help support a "website user account" rather than anything to do with a general ledger in accounting.

Ah, yeah, that makes more sense I suppose, and it explains why they did not work like I thought they would.

Brings me to the question though, is a "website user account" system really in the scope of what bitcoind should be doing?

A good point - personally I think it was probably not such a great idea to have added the commands in the first place (although I can understand why they would have been requested) - the raw transaction commands are definitely something I see as being more useful.

I hate the feature and have not yet found any use for them; they confuse the user for no gain. If they implemented even a very rudimentary way to do manual coin control I'd use them.

The purpose of "accounts" is to automatically adjust balances when there is a block chain reorganization.

Suppose you run a business selling widgets, and Fred sends you 10 bitcoins to buy a widget. If you have associated a receiving address with "Fred's account", that account will show a balance of 10 BTC.

Later, there is a block chain reorganization, and on the new block chain there is no longer a payment from Fred. In that case, the balance of "Fred's account" will show zero. If more blocks are successfully built onto the original chain, the block chain may be reorganized again, and the balance of "Fred's account" will again show 10BTC.

For many businesses, this is exactly what they want. If the business has an ongoing relationship with the customer, they know at all times how many coins they have received from that customer.

On the other hand, it's rather impractical, particularly for businesses with irreversable transactions or with lots of one-off transactions.

In practice, most businesses prefer to wait for (say) 6 confirmations of receiving the payment. The business then credits "Fred's account" (on their database, not in their Bitcoin client) with 10BTC, which the business regards as irrevocable. The widget is shipped to the customer at that point. If, later, there is a block chain reorganization, the widget business carries the loss on their books (although naturally if they know who the customer is they will try to recover the payment).

In normal circumstances, 6 confirmations is sufficient that a block chain reorganization is very unlikely to occur after that point. However, it's possible. When the overflow bug was affected, there was a block chain split that wasn't resolved until each user updated their Bitcoin software. For many users, this took longer than 6 confirmations (people gotta sleep, etc) so many people were running for a while on a faulty block chain that was destined to become orphaned.

(And yes, the ability to let an account balance go negative is a feature, not a bug.)

Interesting - hadn't heard of this explanation before - has a block chain reorg occurred since the API commands were introduced?

Frequently two blocks are announced in a very short timeframe and part of the network works on extending each.  Last one occurred on August 15th.
http://blockexplorer.com/q/reorglog

I would have preferred a low level interface with an optional high level interface.  As it stands the full low level interface isn't exposed, and the high level interface isn't suitable for all applications.

In that case you would benefit from reading some of Satoshi's old posts about "accounts". You could start with these:

The problems with "listtransactions" that are addressed by "accounts":
https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228 (https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228)

Jeff Garzik's counterpoint to the above post:
https://bitcointalk.org/index.php?topic=2151.msg28247#msg28247 (https://bitcointalk.org/index.php?topic=2151.msg28247#msg28247)

Satoshi's simple pseudocode showing how to use the "accounts" feature:
https://bitcointalk.org/index.php?topic=2202.msg28947#msg28947 (https://bitcointalk.org/index.php?topic=2202.msg28947#msg28947)

I strongly agree. I want something where I can specify addresses as inputs.

Bitcoind is ment for coders and admins, and so should expose the most base level interfaces. When I first started with bitcoin development the lack of these features was annoying.

When 0.7 comes out we'll have https://en.bitcoin.it/wiki/Raw_Transactions

^lol, didn't see so much contradictions in the same post until now. How isn't bitcoin an accounting software when it has to account for all the unspent inputs available to it?

Accounts work as ribuck said, for individual user accounting and they provide allot of features when used correctly. Like taking the burden of accounting of your main database and maintaining correct user balances, in case of chain reorgs. You can even have a complete website or app failure and no backups of the main database, but the coins are kept intact in every user's account with only one backup of wallet.dat.

I don't have the time to write a complete documentation, but I can assure you bitcoin accounts are useful and whoever tells you the opposite hasn't got a clue what are used for.

Sorry for the rant, I just turned my back for a moment lol

@weex learn how to "move" coins between accounts and you will see how easy the accounting gets, with no database overhead and it just works. Start using queues in case you want to have your app work smoothly and prevent accounts going negative if it isn't desired. That's all, now keep developing your app, bitcoin is all set-up.

Bitcoind is not accounting software, at least not in the traditional sense of what accounting software is (give me the command for an aged debtors).  As has been explained by others the "account" system is designed to address a very real problem that can occur during a block-chain reorganisation.  ( Good explanation here https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228 )

Once again bitcoind is NOT an accounting program, as I see it its probably best described as a ledger.

Nobody will allow you to keep the ledger that silently wipes out the transactions and changes the timestamps on them. This is what bitcoin{d,-qt} does.

And by nobody I mean that it doesn't matter wheter you run you accounts according to the rules of:

1) Uncle Sam who lives in Washington,DC and charges 28% APY for overdue negative balances.

2) Uncle Vinnie who lives over the bodega and charges 1 finger per month for overdue negative balances.

It is relatively easy to actually keep the real ledger with modified bitcoin{d,-qt}. You need to override the db->put() BDB call to recognize writes to the wallet.dat and store the actual log of calls in some secondary database before calling the original C virtual function. This log will have proper timestamps (not the approximate to 2 hours and even possibly out of order timestamps) and will have a actual log of monies appearing and disappearing during the orphan/reorganization events.

I agree, my calling it a ledger was a total stretch.  My point was that it is not an accounting system and "accounts" in the context of bitcoind is a bit confusing (at least for me, and others it seams judging from posts in this thread).

Don't really know what to call them and "Labels for transactions to track and prevent orphaned transactions showing up in bitcoind listtransactions being taken literal" is kind of a mouth full.  ;D

In the end I suppose "accounts" is as good a term as any, but it does tend to lead to confusion.

I read through the links you gave (and thanks for the interesting reading) but still don't see how anything written there describes that the purpose of "accounts" is to automatically adjust balances due to a block chain reorg (it seems to me that reorgs are just something that has to be handled in order for it to give meaningful results with listtransactions).

AFAICT the purpose of "accounts" is to be able to divide tx's into separately labelled groups (much the same as in normal accounting with a GL) and thus to be able to get balances for each group (i.e. a "group" is an "account").

Perhaps if you replace the word "purpose" with "implementation" that might be closer, however, the implementation could have easily been written to use a previously "labelled" address as the only input address for a "sendfrom" without changing the purpose at all. I assume the reason it wasn't done this way was to keep the pseudo-anonymity as strong as possible (which is something completely unlike the way any normal accounting works).
 

No, the main reason isn't anonymity the reason is so transferring bitcoins between accounts using 'move' doesn't require a blockchain transaction.

I still don't understand why the official client is smart enough to allow me to use the address book feature and CUSTOM LABEL incoming and outgoing addresses, but the API is too useless to use a common call to retrieve that same information from sends/receives in a dynamic transaction array.

Oh well....I made THAT thread ages ago and people thought I was retarded for suggesting such a thing.

Unfortunately I am not a coder, but listtransactions()-->LABEL sure would be a nice (although semi-redundant for 'accounts' ) addition....

Aha - this is beginning to make some more sense - is there an explanation of how the mechanics of the "move" command actually works documented somewhere (other than in the code)?