Do not use address if it has an existing label

[Jacksper13]

You can currently see the list of all addresses from the addresses tab. You can go to the next unused address and "reserve" it for a specific purpose by adding a label to an address that still hasn't received any funds.

"Reserving" addresses is typically done to pre-share addresses with third parties. I want John to pay me, I will send him this addess. I want Alice to pay me, I will send Alice this other address. I type "payment from John" and "payment form Alices" in their respective Label fields. However, I don't control when they are going to make the payment. They may wait until fees get a bit lower, or until they themselves get paid for another job or whatever.

However, these addresses are just "unused" addresses, and Sparrow doesn't treat unlabeled unused addresses any different than labeled unused addresses.

Say, in the example above, after I share those addresses with John and Alice, I want to consolidate two coins. I go to the coins, I Send Selected, I select Pay to: this same wallet (Consolidation), and the suggested address is the next unused address, labeled or not. This means I will consolidate to an address I decided to label while it was empty, and when John or Alice pay me, I will be incurring in address reuse, because I shared them the address before I did the consolidation

The suggestion here is that Sparrow understands that unused labeled addresses are different from unused unlabeled addresses. If it is labeled, the user probably already shared it, or has a usecase in mind, and it is therefore NOT safe to use by Sparrow. EXCLUDE this address form the list of usable addresses for change, consolidation, or receive form other wallets.

[RequestPrivacy]

The suggestion here is that Sparrow understands that unused labeled addresses are different from unused unlabeled addresses. [...] EXCLUDE this address form the list of usable addresses for change, consolidation, or receive form other wallets.

Nice idea! I would suggest that it doesn't apply to ALL labeled addresses but only the ones that are marked with a keyword e.g. in the label field (but could also be a dedicated option like a checkbox "reserve this address" within the receive tab).

[Jacksper13]

I thought about that too... But the extra user friction added to a checkbox makes it almost painful. Besides, I couldn't think of a single example where you would want to add some text in the Label of an unused address but not reserve it, the fact that you add text means you have some use in mind for that address after all, no point on adding text otherwise.

Can you think of an example where you would want to add a label to an unused address, but you would be ok with the app using it for a consolidation and overwriting your previous label?

[RequestPrivacy]

No, not really. Maybe I could think of some far fetched and constructed examples but what would be the point...

So to understand you correctly, you want to label and therefore reserve the addresses in the address view and/or in the receive screen? Bc in the later it was my understanding that once you hit "Get Next Address" Sparrow will treat the "consumed" address exactly like you described (as non-usable in the future)?!

[Jacksper13]

I was thinking more in the addresses view, but I guess in the receive makes sense too. If I add a label in the receive screen I also have a plan for it, so for all purposes treat it as "consumed".

I don't really know how the "Get Next Address" works, but you got the gist of it, if I add a label to an empty address Sparrow should not suggest it as a valid receive address, and should treat it as consumed and non-usable in the future. I will make sure to use it myself outside of sparrow (that is why I added a label while it was empty after all).

We can go a step further and differentiate labeled empty addresses from actually used addresses. Addresses used at least once should never be used again in the future, period. Labeled empty addresses should never be used, as long as they remain labeled and unused. If a user removes a label from an empty labeled address, I would interpret that whatever goal they had in mind for that address, they no longer do. So the address can be used once again by Sparrow. Again, this might be too convoluted, and if it's easier to go with "just consume the address forever" it's fine too. It's just an evolution of the proposal to try and improve the automation to user needs

[RequestPrivacy]

Yes I see your point entirely.

If a user removes a label from an empty labeled address, I would interpret that whatever goal they had in mind for that address, they no longer do. So the address can be used once again by Sparrow.

Maybe not, since this address might now be more or less known/public to outsiders so it's good practice to still treat it as non usable in the future.

A remaining question mark for me is how this feature will be handled if you manage the same wallet on different instances e.g. on Sparrow GUI and Sparrow server as it's solely based on labels and these are instance specific. But I guess that's also rather a niche edge case.

[craigraw]

This is an interesting idea - I'm considering the implementation.

A remaining question mark for me is how this feature will be handled if you manage the same wallet on different instances

This is one case where an integration into labelbase.space would be useful.