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.
Topic: Bitcoinqt slow - possible solution (Read 848 times)
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.
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.
0.1 BTC to the man who can help out with a solution to speed it up!
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)
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.
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)
is rpc connecting to localhost/127.0.0.1 or is over a network ? ( assuming network is obviously working perfectly)
Is there no one? 
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.
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.
Jump to: