Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: nicehashdev on June 18, 2014, 05:26:12 PM



Title: Bitcoinqt slow - possible solution
Post by: nicehashdev on June 18, 2014, 05:26:12 PM
Bitcoinqt is processing all RPC calls very slowly. My guess is due to many transactions. Idea to speed it up is following; move all coins from the wallet to another address which would merge all current transactions into one big input for next transactions.

I want to keep bitcoinqt accounting intact (all account balances there must be intact), so the idea is to do following:
1. create new receiving address with account name: "blabla"
2. send all bitcoins to that receiving address (payment to self)
3. issue rpc command: move blabla "" [btcamount]

I need input from bitcoin experts whether this would have any impact on speed of rpc calls. Rpc calls that are used are: sendfrom, move and getbalance.

Thank you for your help.


Title: Re: Bitcoinqt slow - possible solution
Post by: nicehashdev on June 19, 2014, 09:21:17 AM
Is there no one?  ???


Title: Re: Bitcoinqt slow - possible solution
Post by: Justin00 on June 19, 2014, 10:56:17 AM
i'm not expert but if your wallet has heaaaaps of transactions perhaps that is causing the slowness as you have suggested ?
is rpc connecting to localhost/127.0.0.1 or is over a network ? ( assuming network is obviously working perfectly)


Title: Re: Bitcoinqt slow - possible solution
Post by: nicehashdev on June 19, 2014, 11:58:47 AM
i'm not expert but if your wallet has heaaaaps of transactions perhaps that is causing the slowness as you have suggested ?
is rpc connecting to localhost/127.0.0.1 or is over a network ? ( assuming network is obviously working perfectly)

Localhost. What I don't understand is why rpc command getbalance of account takes long time, because that one should be fast regardless of number of transactions. So I am missing a point somewhere... I don't want to perform this big transaction to self if there would be no effect, because it would only cause service to be offline for some time, nothing more.


Title: Re: Bitcoinqt slow - possible solution
Post by: nicehashdev on June 22, 2014, 05:59:09 PM
0.1 BTC to the man who can help out with a solution to speed it up!


Title: Re: Bitcoinqt slow - possible solution
Post by: GoldenWings91 on June 22, 2014, 06:39:11 PM
If your wallet has a lot of addresses it will have a significant impact on performance as the Bitcoin client will be scanning new inputs and checking them against each "address" you own.


Title: Re: Bitcoinqt slow - possible solution
Post by: grue on June 22, 2014, 06:53:26 PM
You really shouldn't be merging your inputs. Doing so impacts your ability to do multiple transactions (because you need to wait for the previous transaction to confim) and it provides no benefit in terms of transaction priority or transaction fees. Also, using bitcoin core's accounts feature is highly not recommended.


Title: Re: Bitcoinqt slow - possible solution
Post by: DeathAndTaxes on June 23, 2014, 10:40:44 PM
The advice you don't want to hear is don't use accounts in bitcoin core.  It is the advice I have been giving for more than a year now.  You are just painting yourself into a corner and then trying to come up with elaborate ways to workaround the problem.  It is very possible support for accounts will be completely removed from a future version of Bitcoin because it is bad and probably never should have been included.

However my guess is you will ignore that so, yes temporarily reducing the number of unspent outputs will marginally improve account performance but in time as you receive new outputs it will get worse again.  Also the other factor affecting performance is the number of accounts so unless you are planning on your service getting less popular over time you will always be swimming against the current.

For any new developer, Rule #0: D not use "accounts" in Bitcoin core to support a multiuser service.  Eventually it would hurt you and by then your entire codebase will be dependent on a very buggy, performance constrained feature which has an uncertain future.