Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: p2pbucks on May 20, 2014, 04:25:44 AM



Title: how many accounts bitcoind core 0.9+ can handle
Post by: p2pbucks on May 20, 2014, 04:25:44 AM
I am planning to run a service on bitcoin node ( bitcoind core 0.9+ )
I wanna know :

1.how many accounts one bitcoind can handle ?

2.how many transactions(including send & move) can be processed by bitcoind in one second ?

3.What's The limits of keypool ?

Thanks :)


Title: Re: how many accounts bitcoind core 0.9+ can handle
Post by: DeathAndTaxes on May 20, 2014, 04:30:56 AM
Not enough.  There is no hard limit but the more accounts and the more unspent outputs the worse performance becomes.  Don't do it.  It is a technological dead end and once you build your entire service around it you will be trapped.

You wouldn't use online banking to act as an accounting ledger.   You would use an accounting ledger and then use online banking as a tool to report incoming funds and process outgoing payments.  Bitcoind is a bitcoin transaction engine. Build your account infrastructure into your application at the data layer.


Title: Re: how many accounts bitcoind core 0.9+ can handle
Post by: p2pbucks on May 20, 2014, 08:12:53 AM
Not enough....


I understand , Thanks  :)

so how many tx can be processed by one bitcoind in one second ?

Should i create several bitcoind to make tx more efficient ? 


Title: Re: how many accounts bitcoind core 0.9+ can handle
Post by: DeathAndTaxes on May 20, 2014, 01:19:51 PM
If you mean how many txs (as opposed to # of outputs using sendmany) can bitcoind create, it is very low, something on the order of 1 tps. Keep in mind 1 tps is >80,00 tx per day, which is more than the entire network is processing today.  That also assumes you are just using bitcoind to create and broadcast txs.  If you are using a single node to query for incoming tx, confirmations, new blocks, etc then that is going to cut into your transaction rate.

You could use multiple bitcoind servers if needed but if your tx volume is that high you should reconsider your model.  We use multiple bitcoinds but it is for redundancy and to detect network issues (isolation, double spend attempts, tx mutability, etc) instead of out of a need for higher throughput. At a minimum you should be queuing up outgoing payments and sending them as multi output txs by using sendmany, or using rawtransactions.


Title: Re: how many accounts bitcoind core 0.9+ can handle
Post by: telepatheic on May 20, 2014, 07:38:58 PM
You should be able to create well over 100 transactions per second on a good computer, but you should create the transactions within your own application (not within bitcoind) and just give bitcoind raw transactions to send to the network. Bitcoind doesn't scale very well at all as a wallet and is more aimed at personal use.

Creating a good wallet is quite difficult as you need to manage a lot of keys and a lot of transactions and do so in an efficient way. The way you do this is dependent on your service (size of average transaction, value of average transaction, number of users, number of transactions, number of individual keys, privacy, security etc.)


Title: Re: how many accounts bitcoind core 0.9+ can handle
Post by: fbueller on May 21, 2014, 02:35:46 AM
Definitely agree with DeathAndTaxes and telepatheic in the points they make.

Bitcoind accounts have problems like randomly ending up with no balance, or sometimes not even accounting for the balance your wallet reports with getinfo(). Performance issues aside, you have very little management over what happens, and it encourages bad practices in your code.

There is almost definitely a library to create raw transactions, keys, sign transactions in your language at this stage. Realistically you want to minimize the use of bitcoind in your application. You don't want to have functionality broken if your site goes down. Delegate it only so much, and take care of the rest in your code.

Keypool always contains around 100 addresses. As you remove the oldest keys, newer keys will be added to the other.