-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some users think they only have 5 addresses #512
Comments
After trying it out some more, its worse than I though: I can't figure out how to get a new address other than the ones listed. :( |
Electrum will automatically create new addresses as they are used. One of the main issues with allowing users to create new addresses at any time they want, the process for automatically regenerating a wallet from seed would need to be more complicated. If you need more addresses for some reason, you can set the gap limit (I think this is only available via the command line now) to a higher value, and it will create more addresses the next time it starts. So basically, Electrum isn't showing a fixed number of addresses, it's showing a fixed number of unused addresses at the end of its sequence. As addresses are used, they are moved to a collapsed "Used" section and users should realize they should select a new address. |
I tested it and it doesn't appear to repopulate the list as addresses are used. Is this perhaps a recent bug? You can see it in the default watching wallet you get, the top address in the list (not the used list) has a non-zero balance. Regardless, the current UI empirically results in users believing they need to reuse addresses, so thats a sign something should be tweaked if not support for any particular tweak. I'm not suggesting that it just display more addresses, since that indeed would result in having to scan further as users could use them in any random order. I'm suggesting that when users ask for address instead of presenting a list of potentially already used ones, just give them the next not-yet-issued address. |
the address doesn't move to Used until the funds are spent. Then if you received more funds, it would move out of Used. Perhaps there needs to be a 3rd category, Used (empty), Used, and Available or something like that. As for requesting a new address, perhaps the simple interface could work the way you're describing. |
Hm. Well the task of receiving coins is really not the same one as managing the keys in your wallet. Reviving should be centered around allowing you to enter in metadata and it should just yield the next unissued address. Key management is orthogonal. So perhaps what should happen there is that there should be an advanced-only key-management tab "Keys", and a receive panel. I'd be interested in if someone can come up with a design better than the one in bitcoin-qt git. |
The address list is repopulated only once the previous transactions have 2 confirmations; this is to prevent blockchain reorgs from creating gaps behong the gap limit. |
Nowadays, every app I have ever downloaded on my phone has some silly tutorial with a rabbit that has to explain everything. Maybe we should have a rabbit explain the way deterministic wallets work? (tutorial on first startup) (joking about the rabbit part) |
Would it help if "Used" was in red or some other color? Eye-gravity makes it easy to miss that here is even a Used tab. |
* Added ability to sort by columns (date, amnt, etc) * Make amnts sort right - customize QTreeWidgetItem * Sort addresses by column * Sort UXTOs by column * Sort status columnn (0) by status then confs * Change float to int, keep it in try clause * Make customized QTreeWidgetItem shared * Use shared TreeWidgetItem * Use shared TreeWidgetItem * Use shared TreeWidgetItem * Use shared TreeWidgetItem * Keep style * Keep syle * Keep same style
From #bitcoin IRC:
ah, I see in Electrum there are five addresses
The receive tab really shouldn't show a fixed set of addresses as this (empirically) makes users believe they must reuse addresses. Instead, receive should not show a list of historical addresses (they should be on some history page), and should just have a give me an address button with some fields for entering labels.
The text was updated successfully, but these errors were encountered: