[Poll] Accounts in bitcoind

[Strider Hiryu]

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.

[ribuck]

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

Interesting - hadn't heard of this explanation before

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

Jeff Garzik's counterpoint to the above post:
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

[PrintCoins]

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.

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.

[notme]

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.

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

[paraipan]

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.

^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.

[NRF]

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?

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.

[2112]

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.

[NRF]

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

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. 

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

[CIYAM]

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

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).
 

[Gavin Andresen]

... 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.

[bitlane]

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....

[CIYAM]

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

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)?