Electrum 4.6.1 (offline): Tried to pre-generate 1000 receiving addresses but onl

[jedlee]

Environment: Windows; Electrum 4.6.1; Standard wallet (SegWit/bech32, bc1…); offline computer.
Goal: I want to pre-generate and export around 1000 receiving addresses for offline use and website import (addresses only, no xpub exposure).

I followed tutorials and ran the bulk generation process, then restarted Electrum, but the “Addresses → Receiving” tab still only shows around 30 addresses. No error messages appeared.

I’d like to ask:
1️⃣ Is this method the correct way to bulk-generate addresses?
2️⃣ If not, is there any other official or recommended way to generate and export many receiving addresses at once?
3️⃣ Could this be related to the gap limit (unused address limit)?

I can provide screenshots of the console and addresses page.
Thanks in advance for your help! 🙏

[rat03gopoh]

1. Yes
2. I don't know, I've never wanted to display that many addresses with Electrum.
3. Yeah, the usual GUI won’t necessarily show thousands because of Electrum's address-discovery/gap behavior^[*].

[*] https://bitcoin.stackexchange.com/posts/35557/revisions

[nc50lc]

I’d like to ask:
1️⃣ Is this method the correct way to bulk-generate addresses?
2️⃣ If not, is there any other official or recommended way to generate and export many receiving addresses at once?
3️⃣ Could this be related to the gap limit (unused address limit)?

[1] Yes, in the "Console" tab (View->Show Console), use the command: [wallet.create_new_address(False) for i in range(980)]
That'll derive 980 more receiving addresses past the already derived 20; derive 970 if you want to include the change addresses to the 1000 total.

[2] You may use the menu: "Wallet->Private keys->Export" after using the command above and it'll export all of those keys in your preferred format.

[3] Yes, Electrum uses the commonly used gap limit of 20 for receiving addresses; then 10 change addresses.
Thus, that 30 addresses that you see.

BTW, since those are derived from a seed, make sure not to leak the seed or even the xpub from the offline machine in any way.

[pooya87]

1️⃣ Is this method the correct way to bulk-generate addresses?
2️⃣ If not, is there any other official or recommended way to generate and export many receiving addresses at once?

It depends on the reason why you are generating large amounts of addresses all at once (what are they used for). I'd say the easiest way to generate a large number of addresses is using a library (BIP-39 or Electrum implementation) to simply derive n number of keys/addresses in a simple loop.

[Pmalek]

Yes, in the "Console" tab (View->Show Console), use the command: [wallet.create_new_address(False) for i in range(980)]
That'll derive 980 more receiving addresses past the already derived 20; derive 970 if you want to include the change addresses to the 1000 total.

Won't generating that many receiving addresses in Electrum cause the software to freeze or even crash? There was always talk about Electrum not being as suitable for such tasks as Bitcoin Core for example. What is the upper limit for generated addresses and gap limit increase before Electrum starts failing?

[nc50lc]

Yes, in the "Console" tab (View->Show Console), use the command: [wallet.create_new_address(False) for i in range(980)]

Won't generating that many receiving addresses in Electrum cause the software to freeze or even crash?

1000~10000 addresses is easy enough, I've even tested that before at least on a mid-range hardware.
But for the upper-limit, I haven't done some benchmarking but some threads report that their client freezes at 50,000 addresses even with high-end hardware.

[gunrose2003]

What do you mean"client freezes at 50,000 addresses"? the account of electrum desktop software is unavailable?

[pooya87]

What do you mean"client freezes at 50,000 addresses"? the account of electrum desktop software is unavailable?

Electrum software and its user interface is not designed in the way to hold and show a very large number of addresses, therefore when the address count grows past a certain threshold it starts becoming slower as it consumes more of your PC resources and eventually it hangs/freezes after it can't process them any longer.

[nc50lc]

What do you mean"client freezes at 50,000 addresses"? the account of electrum desktop software is unavailable?

I see that there's a misconception here that Electrum is like a bank "account", it's not.
There's no central server that can freeze your bitcoins in Electrum.

Take note that Electrum is a "self-custodial wallet" where it stores master extended private/public key and its derived addresses in its keystore rather than relying on user accounts.
And when the number of addresses became too much for a light-weight client like Electrum to handle, its GUI (Graphical User Interface) could freeze a.k.a. become unresponsive.

Take this thread for example: /index.php?topic=5534267.0

[hosemary]

But for the upper-limit, I haven't done some benchmarking but some threads report that their client freezes at 50,000 addresses even with high-end hardware.

Correct me if I am wrong, please.

Elecrum would freeze when trying to get the balance and transaction history from the servers.
Since OP wants to generate addressses on an offline device, electrum would still work fine, even if he wanted to generate 50,000 addresses.

[nc50lc]

Elecrum would freeze when trying to get the balance and transaction history from the servers.
Since OP wants to generate addressses on an offline device, electrum would still work fine, even if he wanted to generate 50,000 addresses.

Those reports that I mentioned said that it would freeze for hours just by checking the addresses tab, syncing the wallet isn't mentioned.
Depends on the person's machine and Electrum's version perhaps. Remember that I didn't specified a specific limit since I haven't done any benchmarks.

High-end machines may not freeze at 10x or more that amount.
My machine can handle as much as 300,000 addresses but Electrum is laggy when opening the wallet or checking the addresses.
Offline of course.