We use the standard client in our business. The wallet already contains about 25k addresses. Will the wallet remain stable after the number reaches 100k or a million addresses? I was told that all major business have forked the client. Should we also fork and code our own wallet?
13
-
Related: How to handle a ridiculous amount of receiving addresses – Murch♦ Dec 29 '13 at 21:25
5
I've ran tests before on .5 million addresses generated in one afternoon. It fired walletnotify within the milliseconds, no noticeable delay when I sent an amount to a random address. Only noticeable thing was that the client took 30 minutes to start up, which I guess is fine if you run a larger service. Only thing that may trouble you is slow transaction creation time, but someone on here advised me to just move the funds into a new address monthly.
-
How will it behave once you have multiple transactions involving all those addresses though? I guess the advice to move all the funds to a new address monthly is to solve that issue? – Emre Kenci Dec 29 '13 at 21:44
-
Transaction size, and therefore fee, will become greater the more spread your funds are. Although I'd assume that moving them to a central address should solve it as a singular unspent output is created from many. – John T Dec 29 '13 at 22:46
3
Regular BitcoinQT client is not suited to run a huge amount of addresses/transactions. The database easly goes to the roof in a month with IO operations, if you do, let's say, 1 transaction per minute. Please consider reading blockchain directly, or use external service, which will handle the overhead for you, ie. Blockchain.info
-
Assuming we use outside service for walletnotify and blocknotify on the addresses we keep in our wallet. (Like adding them as a watch only address) Won't the client still pull transaction data related to our addresses from the network? And therefore have the db go to the roof again? – Emre Kenci Dec 29 '13 at 21:46
3
I tested this by programatically adding 1 million addresses to the QT client via the JSON-RPC interface from a Java program. Rescanning was turned off so all it did was add the addresses and not confirm the balances. It took around 24 hrs to add 1 million addresses and then it took another 4 hrs or so to restart the client and scan the 1 million addresses. I was using a MacBook Air so not very powerful hardware. Still, given the amount of time it took to do the rescan I would not recommend using the QT client with that many addresses in a production setting. Good luck.
-
Your test might not be sufficient to predict what will happen in real life scenarios that involve millions of transactions and possibly hundreds of accounts in the wallet. – Emre Kenci Jan 2 '14 at 14:28
2
It all comes down to historical data. Do you retrieve historical data by querying the blockchain or do you rely on your own transactional data in a local DB? If you do the latter and you are concerned about the stability of your overloaded wallet you can always switch to a brand new, clean wallet with only the preloaded 100 addresses and be confident that up to the 25K point everything will be smooth and running.
