max addresses supported by a single wallet

[c0ldfusi0nz]

I'd have posted in the developers forum by I'm constrained by my newbie status. Can anyone link me to documentation about the maximum / recommended max number of addresses you should have in a single wallet? The only documentation I've been able to find on the bitcoin wiki is "Running getnewaddress too often, however, will cause your wallet to become filled with many empty addresses. It is therefore recommended to in some way limit the number of unfunded addresses each user can request."

Is there a point at which you'd experience performance degradation?

[DannyHamilton]

I'm not aware of any specific limit or rule-of-thumb numbers.  I believe it depends quite a bit on the capabilities of the particular cumpouter you happen to be using.  There is probably also some dependency on the version of client software you are using.  Do you expect to be needing to generate hundreds of thousands of addresses for some reason?

[Stephen Gornick]

Is there a point at which you'd experience performance degradation?

With versions of the client earlier than the yet unreleased v0.8 the Bitcoin.org client had to do a ton or work with each spend and used a database that wasn't a great fit for the job.   With v0.8 the wallet.dat is still bdb, but a good chunk of the heavy lifting has been made easier by the switch to LevelDB.  So this means the problem with having lots of addresses and transactions in the wallet experience with versions prior to v0.8 should drop significantly if not disappear entirely.   I don't know if any benchmarks have been performed with v0.8 to know where the bounds are.  Under versions prior to v0.8, having as few as a thousand addresses with transactions caused behavior to range from "sluggish" to "unacceptable", depending on your hardware.

At some point in the future the Bitcoin.org client won't even use bdb whatsoever (not even for the wallet) anymore.

[K1773R]

so can i make now a wallet.dat with ~46M keys?

[drakahn]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

[K1773R]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

is there a way to import a huge list of privkeys? pywallet dosnt work for that nor for the new wallets

[drakahn]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

is there a way to import a huge list of privkeys? pywallet dosnt work for that nor for the new wallets

You could make a script that parses the list of private keys into separate importprivkey commands

[K1773R]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

is there a way to import a huge list of privkeys? pywallet dosnt work for that nor for the new wallets

You could make a script that parses the list of private keys into separate importprivkey commands

every import means chainrescan, maybe i should do this on a offline bitcoind, otherwise its going to take longer than im alife i guess

[drakahn]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

is there a way to import a huge list of privkeys? pywallet dosnt work for that nor for the new wallets

You could make a script that parses the list of private keys into separate importprivkey commands

every import means chainrescan, maybe i should do this on a offline bitcoind, otherwise its going to take longer than im alife i guess

I did not know that, If offline doesn't work (still scanning the blocks you have), I guess you could set up a closed circuit of clients that only connect to each other and only have early blocks

[K1773R]

so can i make now a wallet.dat with ~46M keys?

I made one a while ago with keypool set to 100M I don't know how many it actually made but I stopped it at ~100MB of wallet.dat, it felt like it took a few extra seconds to open but seemed to work fine past that

is there a way to import a huge list of privkeys? pywallet dosnt work for that nor for the new wallets

You could make a script that parses the list of private keys into separate importprivkey commands

every import means chainrescan, maybe i should do this on a offline bitcoind, otherwise its going to take longer than im alife i guess

I did not know that, If offline doesn't work (still scanning the blocks you have), I guess you could set up a closed circuit of clients that only connect to each other and only have early blocks

nah was talking about a fresh (no blocks, beside the genesis one) and offline bitcoind, as soon everything is imported move the wallet to a online bitcoind or just let it sync.

[c0ldfusi0nz]

I'm planning on building a marketplace service, thus in order to be scalable I'd like to know how many addresses the wallet can support. Otherwise I suppose I should add in logic to reuse stagnant addresses.

[gweedo]

I'm planning on building a marketplace service, thus in order to be scalable I'd like to know how many addresses the wallet can support. Otherwise I suppose I should add in logic to reuse stagnant addresses.

I wouldn't even worry, worst cause if your wallet gets too big (which is in 100's of millions) then you just create a new wallet.dat and sweep your funds into one address in there.

[toz]

so can i make now a wallet.dat with ~46M keys?

Try it, and if it works badly, profile the code and see where it breaks. I doubt the client is optimized for millions of accounts.

[Stephen Gornick]

every import means chainrescan,

With the Bitcoin.org client v0.8, that is a configurable option so you can do multiple importprivkey with no rescan and then when you are done do the rescan.

[buffett]

i'm sorry to bring this old thread back.

any update with the latest bitcoind? any significant issue when bitcoind has 100k or more accounts/addresses? thanks

[gweedo]

i'm sorry to bring this old thread back.

any update with the latest bitcoind? any significant issue when bitcoind has 100k or more accounts/addresses? thanks

No issues, 100k addresses are nothing compare to most sites and people. So don't worry.

[buffett]

i'm sorry to bring this old thread back.

any update with the latest bitcoind? any significant issue when bitcoind has 100k or more accounts/addresses? thanks

No issues, 100k addresses are nothing compare to most sites and people. So don't worry.

that is great. so what about 1M, 10M, 100M or even 1B addresses? has anyone did a benchmark of the performance?

there is no way i could get 100M transactions (maybe only in my dream), though i'm still curious