Why are the Receive tabs in some wallets becoming less user-friendly?

[Forsyth Jones]

I'm a long-time user. I've followed the development of many wallets: some died, new ones emerged, others updated, got better, got worse... but when it comes to UX, most fail, especially in how they present receiving addresses to users:

Normally, in older versions of Electrum (<4.0), Electrum provided a Bitcoin address right away, description, amounts fields, where there was a dynamic QR code that changed as the user filled in the fields...

Now, in Electrum 4.0 versions, the address is no longer presented right away, and the QR code as well, that is static. You have to click on Request to view the next address, to generate a QR code with description and amounts, you have to fill in the fields and click "Request", but a new address is generated every time you click "Request," and right below, a list of Requests appears. You can set the expiration of each Requests, delete them, but you cannot edit them (description, request amount, etc). You are forced to gen a new request with a new address every time...

The problem is that this makes me lose control of my addresses and others problemns, besides that, I have to press many buttons to: gen new requests, delete expired requests... this creates immense confusion for beginners, because beginners will think that Bitcoin addresses expire, when is not true.

When requests expire or you delete them, the addresses generated by those requests go back to being shown again if you generate new requests again.

In Bitcoin Core, it works similarly, but here, once you click on "Create new receiving address" the addresses are not displayed again. If you want to access the address that was generated previously, you have to go to the list of Receiving Addresses and copy the address, but you can no longer generate QR Codes with that same address again, nor change the amount, new Bitcoin URI, etc... question: why is that, developers?

It seems that theses wallets treat their wallet addresses as "Invoices," meaning they generate a new invoice (new address) every time the user clicks Receive/Request... some users (like me and I believe more people too) want to see again EXACTLY a specific address and generate URIs, QR Codes for that address... why not?

Bitcoin addresses are not invoices. The UX of Bitcoin Core's receive tab is ugly. The "Requested payments history" list, the requested address is not even displayed (you have to click on the Request to see the QR Code), and the QR code is static for that label, amount, and message filled in by the user at the time the invoice was generated... why is that?

In many cases, the user won't receive Bitcoin exactly at the moment they request a new address, they are testing the wallet, getting familiar with it. In the past, Bitcoin Core had an option for you to generate a bitcoin URI with previous addresses (you had to check a checkbox). They removed it. Why? Why? This doesn't represent any threat to security and privacy (unless you know what you are doing). It's not the first topic I've brought up about wallet usability, but it seems that with each new version of these wallets, the developers remove features without consulting the users themselves. Why not just leave what already simply works? 

Do you also have this impression?

For those who read this far and still haven't understood my point, I miss having the feature of dynamic QR Codes in wallets (which changes as the user fills in/edits the label, amount, etc, fields) or of generating a request for an address generated previously that HAS NOT YET BEEN USED. That's what I'd like to see back. But the impression I have is that, especially these 02 wallets, they remove or depreciate features without consulting users. You don't remove features unless they are replaced by a better one or without consulting users first.

I'm venting here because I'm a user who thinks about my practicality. I want logical solutions without the need to press more clicks when I can solve them or create them with 1 or 2 clicks....

Developers, understand that you removed features that already worked very well and efficiently and replaced them with interfaces where the user has to click on more options (right-click) to access the same feature that was previously easily accessed with a few clicks. For instance: They removed dynamic QR Codes, now they treat addresses as invoices (they are not invoices and never should be). I don't want to repeat the address, but I also don't want the interface to generate new addresses WITHOUT CONSULTING ME OR WITHOUT ME CLEARLY INTERACTING TO GENERATE a new address.

And why am I focusing on dynamic QR Codes?

Because it's very useful for the merchant or seller who interacts with multiple people at once. Let's do an analysis with credit card POS machines: you enter the amount to be charged and it shows a QR Code for the customer to pay (if your country has an instant payment option like PIX, Zelle, etc), and some wallets don't even have this characteristic anymore, they just drop the address on the interface, and the payer has to enter the amount.

[nc50lc]

-snip- this creates immense confusion for beginners, because beginners will think that Bitcoin addresses expire, when is not true.

I can't comment on most of your points since I'm not the one who designed those, but this part is their (newbies) issue if they don't read.
Electrum has tooltip that explains exactly that on the expiry dialogue box:


For Electrum >v4.0 Receive GUI, they had to update it to implement lightning invoice (more reasons for you to hate Electrum's LN?)
Not sure why they disabled that dynamic QR for on-chain though.

Good job on keeping it here instead of their repository since it looks like personal rather than a representation of the majority of those wallet's users.

[ABCbits]

The problem is that this makes me lose control of my addresses and others problemns, besides that, I have to press many buttons to: gen new requests, delete expired requests... this creates immense confusion for beginners, because beginners will think that Bitcoin addresses expire, when is not true.

These days i simply visit "address" tab or page that show list of generated addresses, then add label and copy unused address.

It seems that theses wallets treat their wallet addresses as "Invoices," meaning they generate a new invoice (new address) every time the user clicks Receive/Request... some users (like me and I believe more people too) want to see again EXACTLY a specific address and generate URIs, QR Codes for that address... why not?

Those wallet probably want to encourage principle of "one time address" that could improve one's privacy, but i agree the UI/UX isn't really smooth.

[Forsyth Jones]

I can't comment on most of your points since I'm not the one who designed those, but this part is their (newbies) issue if they don't read.
Electrum has tooltip that explains exactly that on the expiry dialogue box:

Users by definition, most never read such warnings, especially when they are not clearly visible in the UI. In this case, the user has to click on 'Expiry' to see such a warning, which means another click step. Usually, most click on 'Request' and immediately grab their address, without customizing the invoice/request.

Usually, people only go after information when they have already made some serious mistake.

For Electrum >v4.0 Receive GUI, they had to update it to implement lightning invoice (more reasons for you to hate Electrum's LN?)
Not sure why they disabled that dynamic QR for on-chain though.

Good job on keeping it here instead of their repository since it looks like personal rather than a representation of the majority of those wallet's users.

Yes, I was going to mention that, but besides not remembering to include it in the post, the text was already getting very long. Due to the implementation of LN, they remodeled the addresses tab to behave like expirable invoices, but I would like there to be at least a way to define the behavior in the settings, it was a very abrupt change. In the case of the removal of the dynamic QR code, it was clearly a downgrade, software updates shouldn't remove features to replace them with something static in this case, that really irritates me.

It gives the impression that the devs think they are the owners of the truth and we users are a bunch of incapable idiots who need to be guided at all times so we don't trip, and even if most are, that doesn't mean I should be treated like an foolish too.

Admit that adding LN to Electrum was a great advancement, I always liked the idea of LN, I was more of an enthusiast in the past, but I prefer onchain while it's viable. I find LN quite useful, I used it these days on Phoenix to pay an invoice, in my case, I use it 1x or 2x a year. My point is about the way it was implemented in Electrum. In this case, they removed the dynamic QR code. I don't like the wallet's behavior of changing addresses WITHOUT FUNDING THEM FIRST or without my interaction/action/authorization/consent, because on this part I have a trigger. I don't like the idea of not receiving to addresses because the wallet treated them as "invoices," dumped the addresses (in the sense of always showing new addresses as if they were invoices, without funding them first), and then seeing that: I received to the index /7 address and only received again at index /14 (addresses were skipped here).

And sincerely, I wouldn't want someone replying with something like: "the wallet doesn't show the same address when you click Request because it assumes you showed the address to someone else or published it online, this violates your privacy." I know that, and in this case, I agree the user should no longer receive to that address, but this depends on the user's action in showing that address to someone else, meaning it's not 100% of the time. This should be under the user's control (like some wallets already do).

These days i simply visit "address" tab or page that show list of generated addresses, then add label and copy unused address.

I also do this: I go straight to the Addresses tab and copy my address from there (always the next one, without reusing an already funded address), because I find it easier and more practical. I just copy my address, without clicking "Request" to only then see my address. In this case:

Receive tab: Address not displayed by default > fill in the fields (optional), click "Request" to view the address and a static QR code (downgrade).

Addresses tab: I just copy the address directly, without beating around the bush, and that's it.

Those wallet probably want to encourage principle of "one time address" that could improve one's privacy, but i agree the UI/UX isn't really smooth.

Yes, indeed it's not easy at all, regarding privacy and etc, I'll use the same explanation I gave to nc50lc above.

[Yamane_Keto]

Use this command.

Code:

electrum getunusedaddress

Electrum GUI Receive tab using this command

Code:

electrum addrequest --amount 0.005 --memo "Invoice #123" --expiration 3600

there are specific allocations, but they are intended to assist beginners. even though the word "expiration" might mislead many.

[d5000]

The problem is that this makes me lose control of my addresses[...] When requests expire or you delete them, the addresses generated by those requests go back to being shown again if you generate new requests again.

I fail to see why this should be a problem, unless you want to re-use your addresses. And that is normally a bad idea.

In general addresses in Bitcoin should never be treated as anything of importance (much less as "accounts" like in Ethereum). It's just a random string connected with your seed. The only time when you need control over your addresses is when you spend coins on them, but if you never re-used them, then you also don't need really control over "addresses" but over "utxos" instead.

So my guess is that the devs simply want to "nudge" the users to use Bitcoin like it is meant to be used, one address per transaction.

of generating a request for an address generated previously that HAS NOT YET BEEN USED.

Again here, simply forget these addresses. You can generate billions of addresses with your seed.

About the dynamic QR codes, I probably agree with you on this point.

[Forsyth Jones]

Use this command.

Code:

electrum getunusedaddress

Electrum GUI Receive tab using this command

Code:

electrum addrequest --amount 0.005 --memo "Invoice #123" --expiration 3600

Only the first getunusedaddress worked for me, the second one didn't work, but I really liked getunusedaddress, it will be very useful for me, see it:

I fail to see why this should be a problem, unless you want to re-use your addresses. And that is normally a bad idea.

But I never said I want to reuse a funded address. I said I would like the next_address to remain locked in the interface until it is funded. Reusing an already funded address is bad for privacy and should not be encouraged.

In general addresses in Bitcoin should never be treated as anything of importance (much less as "accounts" like in Ethereum). It's just a random string connected with your seed. The only time when you need control over your addresses is when you spend coins on them, but if you never re-used them, then you also don't need really control over "addresses" but over "utxos" instead.

I know that.

of generating a request for an address generated previously that HAS NOT YET BEEN USED.

Again here, simply forget these addresses. You can generate billions of addresses with your seed.

It does become a problem because of the gap_limit. For insance, the gap_limit of an Electrum wallet is usually 20 receiving addresses and 10 change addresses. If a user generates a bunch of unused invoices and receives balance to an m/30 address, will Electrum be able to see it without the user changing the gap_limit currently? I don't recall if Electrum monitors gap_limit beyond what was defined, so this is an honest question.

About the dynamic QR codes, I probably agree with you on this point.

I agree with you. Dynamic QRs are very useful. Without them, we have to manually create new requests (which limits productivity, as it requires more user actions, more clicks and etc).

[nc50lc]

Use this command.
-snip-

Only the first getunusedaddress worked for me, the second one didn't work, but I really liked getunusedaddress, it will be very useful for me, see it:

That's because the second command's syntax isn't meant to be used in Electrum's console tab.
Also, the provided command itself isn't correct (missing an underscore), its command line args aren't correctly used like "--amount" which isn't a named arg and others like "expiration" look like misspelled.

For the terminal while electrum daemon is running,
the command should be:

Code:

electrum add_request 0.005 --memo "Invoice #123" --expiry 3600

If you want to use it in the console tab, it should be formatted like this:

Code:

add_request(0.0005,"your_memo",1800)

But this isn't more convenient than using the receive tab in any way.