Automatic receiving address renewal

[imaginaryusername]

If an address received an incoming tx while the cashshuffle plugin is on, the "receive" tab should automatically renew itself without being prompted.

This might be pushable to regular EC without cashshuffle activated too if we do:

• Check whether "use change address" is on; if change address is off the user probably wants reusing address as a feature.
• Check whether wallet is HD. Obviously if not HD this will not make any sense.

This is probably one of the last UX gaps to cover and avoid address reuse after #94. Without this, multiple coins on the same address could be dicey even with proper coin control - especially when multi-input shuffling is not in place.

[cculianu]

Yeah it kinda bugged me too that user had to hit "new" in the receive tab. Most users probably don't bother... Makes sense for regular EC (cashshuffle plugin unloaded) too given the two points you said.

[cculianu]

So I'm thinking:

• if the form is already half-filled out (ie has a description and/or an amount) and they happen to receive to that address (or they just were lazy and never cleared it) they should see a little warning message (maybe a label with a yellow exclamation icon or something) explaining the address is going to be re-used and suggesting they hit new because address re-use is so 2009.

• if they come back to the form after leaving it or it was blank check the presented address and if it's been used.. auto-hit "new" for them without checking. I hope they wouldn't mind.

I'm still a little nervous about the pathologically newbish user that doesn't know about the address tab and wonders why "their address" changed (some users actually think they only get one address!).

Maybe we don't auto-renew the address but instead urge them to use a new one with a yellow exclamation mark icon and a stern talking-to?

Hmm...

[imaginaryusername]

I'll actually recommend renewing under all circumstances without asking as the default behavior - perhaps with a little yellow exclaimation mark and prompt that says "previous address used, refreshing to new address!" in the blank space under the UI when that happens. The user doesn't have to do anything, just be notified about why the change happened. More action needed from users = more room for errors and more frustration, this behavior doesn't do any harm (other than when they disable "use change address", which indicates explicit single address and we should respect) anyway.

This actually aligns the expectation with Bitcoincom/Copay wallet (which covers up the whole receive UI with "received!" when coins come in, then when you go back to receive screen it's a new address). I'm sure bitcoincom/copay is more newbie friendly than EC ;D

Don't think we need to be concerned about the hypothetical newbie user, especially when the address changes every time they restart the wallet anyway :P

[cculianu]

more newbie friendly than EC ;D

Heh. True. But EC is a "transaction studio" :)

Ah, if they do it -- and got away with it -- then the fears about newbie antagonism go away. Sounds good.

Don't think we need to be concerned about the hypothetical newbie user, especially when the address changes every time they restart the wallet anyway :P

Ha ha true, this is a good point. I'm doin' it. Probably will put it in base EC first then merge it forward to CashShuffle + SLP (after clearing it with jscramer)

[markblundeberg]

Related: https://github.com/Electron-Cash/Electron-Cash/issues/968

[markblundeberg]

I'd agree with @imaginaryusername that the tab's first field "Receiving address" should be auto-updated. Saved addresses should not have their address modified, of course.

On second thought.... Maybe that field shouldn't even be shown at all before the address is saved, i.e., until it is reserved. This may be a more intuitive mechanics:

• When nothing in the 'requests' list is selected, nothing is shown on the Receiving address field -- perhaps replace it with a 'New' button.
• When the New button is clicked, it immediately creates a new request and grabs an unused address (reserving it immediately!).
• When request details are edited, it is automatically saved and updated for each keypress. (I.e., no 'Save' button).
• A 'New' button is visible & obvious at all times. Clicking New always makes a new request and reserves yet another unused address.

[imaginaryusername]

If nothing shows up unless you click "new", that makes receiving a two click affair instead of one click (status quo). I'd prefer auto-updating but keep the status quo where address is always shown.

But yes, perhaps the "new" button's role can be expanded.

[cculianu]

Ok, this is done in latest git head. Take it for a spin and let me know if what I came up with works for you guys.

The basic rule is:

• It will blow away the active address in the receive tab if a new tx comes in on it -- IF you enabled "use change address" in the prefs (as per @imaginaryusername suggestion above). Said another way: If you are working on a new request that has not yet been saved, it WILL always re-generate a new address if the current address suddenly receives a tx. (You can test this yourself by sending yourself some coins while editing from another wallet or the same wallet or the txdialog, etc).

• HOWEVER: If you have a saved request that you are editing (by having selected it from the request list table below), it won't blow away anything

• The UI more strongly enforces the relationship between what's selected at the bottom and the current request you see in the form. Before that wasn't always the case.

• The "New" button has been renamed to "Clear" and is always enabled.

• The "Save" button is only enabled when you have actually "unsaved changes". Before this wasn't always the case and sometimes it would stay enabled even if no unsaved changes.

Let me know!

[cculianu]

So one caveat is the code I just committed creates a new address (potentially past gap limit if and only if you have many unpaid requests).

Possible approaches:

• UI doesn't actually update with a new address (and maybe warns you with a label?)
• Create a new address anyway (what my latest commit does)
• Pop up a warning then create a new address anyway (not ideal as this is a passive refresh).

Not sure what to do....