9

On the bitcoin wiki's "Accounts explained" page: https://en.bitcoin.it/wiki/Accounts_explained#Account_Weaknesses

It clearly states:

The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.

So my question is that should the standard web developer creating a bitcoin web app using the RPC interface use (or ever use) accounts?

Should we always use the default "" account since we technically always have to use accounts when accessing the RPC for things like getting the entire servers balance?

Should we just handle our users accounts on our own databases and ONLY use bitcoind for things like listsinceblock() to store transactions and user balances in our databases?

1 Answer 1

8

As mentioned in the page you linked, it is a bit awkward to use Bitcoin-qt's accounts system. Don't bother with accounts as they are intended to be a way to manage your money within the program. When you're having thousands of accounts you are already doing it wrong.

So how do you structure a service to do this?

Handle accounts completely on your database. When you generate an address, store it as a field under a user in whatever database table/collection you have for users. This will allow you to quickly and easily scale your address counts in the event you grow large, Bitcoind does not scale well.

Handling receives

This is awkward to do with the current state of Bitcoind, the program never really intended to support large services. Bitcoind can efficiently detect receives to addresses in wallet. When you use the RPC interface and use the "getnewaddress" command, Bitcoind will store it in it's wallet. I've tested out Bitcoind with a million addresses before, it takes a solid half hour to start up but receives are snappy with no noticeable slowness.

Use walletnotify and/or blocknotify to get new transactions and blocks. Those two are arguments you can put in the bitcoin.conf file that specify a program to run when one transaction or block happens. Walletnotify is called per new transaction to or from an address in wallet.dat and gives a notification when it receives the transaction (unconfirmed) and then again when it's in a block (1 confirm). Blocknotify works per block. See the suggestions on how to use walletnotify here.

Just load the hashes walletnotify gives you in a database and then on block check if each one has enough confirmations, be thoughtful of the fact that Bitcoind usually has 2 walletnotify events per txn (one for unconfirmed and one for when a txn makes it into a block). And make sure the program you call is light weight and quick.

The pro method

This ways a bit advanced, rarely used and you will need some C++/Java/Python/Go proficiency. The community have made many Bitcoin implementations available as open-source libraries you can link to. Many larger services simply need more complexity with receiving transaction and better scalability, which Bitcoind struggles to provide.

It's a lot more work but you can make your own "node" with features you need easily with the libraries available for a wide range of languages. For Java there's BitcoinJ, widely depended on and reliable. For C++ there is Libbitcoin, which has pretty good examples and looks simple. Python has a bunch of node implementations and modules. Even Golang has something pretty popular.

If you need examples, Github has a lot you can find on search.

3
  • 1
    Gavin Andresen also mentioned during his Bitcoin 2014 keynote that the accounts feature may be removed from bitcoind in the next year or so. Jun 13, 2014 at 11:48
  • The accounts feature has now been removed
    – Mikkel
    Apr 27, 2018 at 9:08
  • Hey, this is exactly what I am trying to do, store deposit transactions for each unique user address from the output received from listsinceblock. I would like to ask, when computing the sum of deposits for each unique user address, does one consider transactions only of category receive and generate and ignore all other transactions categories like orphan, immature and send? Aug 3, 2021 at 1:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.