base account name #3664

1. 
   benjiqq commented at 9:55 am on February 13, 2014: none

   The account system has basically a tree structure. I suggest creating a name for the root, instead of using an empty string, i.e. so that the root account has the name “base” for example (“root” could be confused with user access rights). Empty strings are not a good choice for representing data.

   So instead of this

   {u'': Decimal('1.01000000'), u'test': Decimal('0E-8')}

   one would have this

   {u'base': Decimal('1.01000000'), u'test': Decimal('0E-8')}

2. 
   laanwj commented at 11:18 am on February 13, 2014: member

   The account system does not have a tree structure.

   "" is not so much root, as the “use no account account”.

3. 
   sipa commented at 11:33 am on February 13, 2014: member

   If there is anything a root, it is “*”. But even in that case, there’s only a single level (with a default account “”, plus however many others you want).
4. 
   benjiqq commented at 12:42 pm on February 13, 2014: none

   okay, I can always use a base account myself I want to. the semantics are not entirely transparent at first sight.
5. benjiqq closed this on Feb 13, 2014

   ---

6. 
   jgarzik commented at 2:32 pm on February 13, 2014: contributor

   The "" account is pretty lame. We should follow git, and pick a name, but make that default easily changeable.
7. benjiqq reopened this on Feb 13, 2014

   ---

8. 
   sipa commented at 2:40 pm on February 13, 2014: member

   I’d rather get rid of accounts than encourage them further.
9. 
   benjiqq commented at 2:45 pm on February 13, 2014: none

   because of the recent issue? making everything onchain would increase bandwidth - at the moment blockchain tx are 30M/day = 350/sec. all the exchanges do roughly the same (perhaps 50-100/sec).
10. 
    jgarzik commented at 2:45 pm on February 13, 2014: contributor

    That’s a fair opinion, too. I stated on IRC yesterday that all we need is address tagging, quite similar to the old labels. Someone with more time to care for a bolt-on accounting system can take it from there.
11. 
    jgarzik commented at 2:46 pm on February 13, 2014: contributor

    @benjyz No, we are not talking about making things on-chain
12. 
    laanwj commented at 3:52 pm on February 13, 2014: member

    +1 @sipa

    There’s so much broken with it and everyone wants something else from an acccounting system anyway, it’s kind of a layer violation to have it in bitcoind in the first place. Address tagging is enough to implement anything on top.

13. 
    benjiqq commented at 4:57 pm on February 13, 2014: none

    tagging sounds good. are there any proposals for that?
14. 
    Diapolo commented at 9:51 pm on February 16, 2014: none

    Removing accounts sound like a very very nice idea!
15. 
    laanwj commented at 1:57 pm on February 18, 2014: member

    @benjyz A proposal: Leave the tagging of receiving addresses (like in the GUI and the argument to getnewaddress RPC) as it allows linking received transactions to customers, but remove the account ledger semi-balances

    • Rename
      • setaccount to setlabel
      • getaccount to getlabel
      • getaddressesbyaccount to getaddresseswithlabel
    • Rename optional account argument of listtransactions to label
    • Deprecate the move RPC command and any account ledger usage
    • Deprecate the use of the account argument in sendmany and sendfrom as well as getbalance
    • Deprecate the following:
      • getreceivedbyaccount
      • listreceivedbyaccount
      • Not sure about: getaccountaddress. Probably deprecate it. “label address” wouldn’t really be a sensible thing.
16. 
    benjiqq commented at 4:11 pm on March 14, 2014: none

    @laanwj what is the different between label and account? I need a move command to mirror my internal account system. I am ok with how accounts work at the moment, but it’s quite non-obvious how to implement intermediary applications on top of bitcoind.

    A basic use case is this. some merchant/exchange (trusted third party TTP) manages his own ledger. the users have accounts with that TTP. the TTP implements his own (web-) application, which has concepts of users, accounts and balances. the TTP provides a BTC address for deposits. The question is what gets done by an account system (application layer) and bitcoind (address/wallet layer). All of these transactions on the TTP ledger are internal to his wallet.

    So the needed bitcoind base operations would be:

    • set label (label <=> address)
    • unset label (balance goes to the “main” label)
    • move (labelA to labelB)

    The application operations would be:

    • map user to BTC address for deposits (user <=> label <=> address)
    • withdrawal function
    • transact function (moving balances from userA to userB)
    • users and labels are mapped in this database and synced

    Each request from the web application needs a sync with the application database, which is a costly operation. It would be better to have a hook mechanism, so that any outside transaction has a callback.

    It might be a good idea to have an opensource sample application to describe some use cases in detail. I’m not sure what other consumers of bitcoind expect from such an intermediary layer.

17. 
    laanwj commented at 9:39 am on March 18, 2014: member

    @benjyz Labels are simply names for addresses.

    For receiving addresses this makes it possible to attribute an incoming transaction to a certain user or order. That’s all.

    They do not relate to balances. If you manage money for users you need to keep track of your own accounting. This is outside the scope of the Bitcoin Core project.

18. 
    laanwj commented at 9:40 am on March 18, 2014: member

    Closing in favor of #3816
19. laanwj closed this on Mar 18, 2014

    ---

20. DrahtBot locked this on Sep 8, 2021

Contributors
benjiqq laanwj sipa jgarzik Diapolo