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

<p><strong>So how do you structure a service to do this?</strong></p>

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

<p><strong>Handling receives</strong></p>

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

<p>Use <code>walletnotify</code> and/or <code>blocknotify</code> to get new transactions and blocks. Those two are arguments you can put in the <code>bitcoin.conf</code> 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 <a href="https://bitcointalk.org/index.php?topic=203438" rel="noreferrer">here</a>.</p>

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

<p><strong>The pro method</strong></p>

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

<p>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 <a href="https://code.google.com/p/bitcoinj/" rel="noreferrer">BitcoinJ</a>, widely depended on and reliable. For C++ there is <a href="http://libbitcoin.dyne.org/doc/" rel="noreferrer">Libbitcoin</a>, which has pretty good <a href="http://libbitcoin.dyne.org/doc/introduction.html#examples" rel="noreferrer">examples</a> and looks simple. Python has a bunch of node implementations and modules. Even Golang has something pretty popular. </p>

<p>If you need examples, Github has a lot you can find on search.</p>

CC BY-SA 3.0
2014-06-13T11:48:40.347Z
Gavin Andresen also mentioned during his Bitcoin 2014 keynote that the accounts feature may be removed from bitcoind in the next year or so.
Martin Harrigan
CC BY-SA 3.0
2018-04-27T09:08:57.870Z
The accounts feature has now been removed
Mikkel
CC BY-SA 4.0
2021-08-03T01:09:30.127Z
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`?
philosopher
CC BY-SA 3.0
2014-01-26T02:32:09.103Z
2014-01-26T21:58:09.027Z
2014-01-26T21:58:09.027Z
John T
<p>On the bitcoin wiki's "Accounts explained" page:
<a href="https://en.bitcoin.it/wiki/Accounts_explained#Account_Weaknesses">https://en.bitcoin.it/wiki/Accounts_explained#Account_Weaknesses</a></p>

<p>It clearly states:</p>

<blockquote>
  <p>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.</p>
</blockquote>

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

<p>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?</p>

<p>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? </p>

<bitcoind><scalability>
Bitcoin "accounts" feature - Is it practical or scalable?
Sean Edwards
# Bitcoin "accounts" feature - Is it practical or scalable?

(Asked by: username_0 on 2014-01-25)

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?

**Tags:** bitcoind, scalability


---

## 1 answers

### Answer by username_1 on 2014-01-26. Score: 8 | Accepted answer

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](https://bitcointalk.org/index.php?topic=203438).

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](https://code.google.com/p/bitcoinj/), widely depended on and reliable. For C++ there is [Libbitcoin](http://libbitcoin.dyne.org/doc/), which has pretty good [examples](http://libbitcoin.dyne.org/doc/introduction.html#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.

> **Comments:**
> **username_2**: Gavin Andresen also mentioned during his Bitcoin 2014 keynote that the accounts feature may be removed from bitcoind in the next year or so.  
> **username_3**: The accounts feature has now been removed  
> **username_4**: 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`?  

---

