Pay-to-self addresses don’t display, can’t be added to address book #12796

1. 
   jamesob commented at 7:49 pm on March 26, 2018: member

   Found in master c948dc8f4285e27d8c0f3553d9d427b2a7b01b77

   An address generated by the wallet for receiving isn’t displayed by the address book and can’t be added. When the user attempts to add it, an error message is presented saying ‘The entered address “…” is already in the address book.’

   I’m unsure if this behavior is unintentional or not, but it’s pretty confusing.

   Steps to reproduce

   Generate a receiving address

   

   Open the address book from the send interface. Note that the previously generated address is missing.

   

   Attempt to add the previously generated address

   

   Hit warning

   

2. 
   jamesob commented at 8:30 pm on March 26, 2018: member

   Looks like this is a consequence of the address being entered into mapAddressBook with purpose="receive" when the receiving address is created, and then filtering address book display for purpose="send" rows. We then don’t allow the addition of duplicate addresses to the address book, even when the purposes differ.

   One option is to simply not filter addresses for purpose when we’re displaying the address book, e.g.

    0diff --git a/src/qt/addressbookpage.cpp b/src/qt/addressbookpage.cpp
    1index f2ddbf259b..16f96abb73 100644
    2--- a/src/qt/addressbookpage.cpp
    3+++ b/src/qt/addressbookpage.cpp
    4@@ -40,11 +40,6 @@ protected:
    5     {
    6         auto model = sourceModel();
    7         auto label = model->index(row, AddressTableModel::Label, parent);
    8-
    9-        if (model->data(label, AddressTableModel::TypeRole).toString() != m_type) {
   10-            return false;
   11-        }
   12-
   13         auto address = model->index(row, AddressTableModel::Address, parent);
   14
   15         if (filterRegExp().indexIn(model->data(address).toString()) < 0 &&
   

   but that may get kinda dumb for cases when the number of receiving addresses in the book is large.

   Another approach is to rekey mapAddressBook by std::pair<CTxDestination, std::string> where the string is purpose, but that’s more work.

3. 
   jamesob commented at 8:55 pm on March 26, 2018: member

   The kind of repeated pay-to-self behavior that the address book would support probably is edge-casey and not recommended, so this may not be worth fixing.
4. fanquake added the label GUI on Mar 26, 2018
5. 
   ryanofsky commented at 0:01 am on March 27, 2018: member

   Maybe just clarifying the error message would be a good fix? I think

   Can’t add receiving address 2N3… (“ruh roh”) to the sending address book

   could be an improvement over “The entered address 2N3… is already in the address book.”

   One option is to simply not filter addresses for purpose when we’re displaying the address book, e.g.

   It seems like it would be confusing to show receiving addresses in the send dialog by default, but maybe there could be a checkbox giving the option to display them.

   Another approach is to rekey mapAddressBook by std::pair<CTxDestination, std::string> where the string is purpose, but that’s more work.

   I don’t think this would be great, because it would also allow associating different names with the same address. But one way you could allow addresses to be used for both sending and receiving would be to extend purpose field with a “receive+send” option. Or make purpose a set of strings instead of a single string.

6. 
   laanwj commented at 2:23 pm on March 27, 2018: member

   You’re right - this is a design constrain due to how the address book is handled internally. It has always been the case and is not a bug:

   • Sending addresses concern external addresses, to be sent to
   • Receiving addresses are always your own addresses. The receiving address book contains all non-change receiving addresses.

   There has been talk (in #7729) about supporting multiple labels per address (as a future idea). The same underlying infrastructure could be used to support this.

   Also: “address book” has always been the wrong name for the functionality (it’s inherited from Satoshi’s original GUI). It’s a list of historically used (sending/receiving) addresses, not intended to be re-used.

   For the short term it’s IMO best to fix the error message as @ryanofsky says, and regard this as expected behavior.

7. 
   jamesob commented at 3:06 pm on March 27, 2018: member

   Roger that. Thanks for the input, @ryanofsky @laanwj. I’ll file a PR clarifying the error messages.
8. jamesob closed this on Mar 27, 2018

   ---

9. jamesob referenced this in commit f63c4293d2 on Mar 29, 2018
10. jamesob referenced this in commit 16b8c08597 on Mar 30, 2018
11. jamesob referenced this in commit 9066941c76 on Mar 30, 2018
12. jamesob referenced this in commit e8330e4803 on Apr 2, 2018
13. jamesob referenced this in commit c295ddc2dc on Apr 9, 2018
14. jamesob referenced this in commit c2a11b0216 on Apr 9, 2018
15. jamesob referenced this in commit f9b4657dca on Apr 10, 2018
16. jamesob referenced this in commit 13bdfc4960 on Apr 10, 2018
17. jamesob referenced this in commit 1f70094c4c on Apr 10, 2018
18. jamesob referenced this in commit 0ae0421619 on Apr 10, 2018
19. jamesob referenced this in commit 97fc617ed8 on Apr 10, 2018
20. jamesob referenced this in commit 8cdcaee4c7 on Apr 25, 2018
21. laanwj referenced this in commit 25ad2f75f5 on Apr 25, 2018
22. stamhe referenced this in commit 1032bf65fe on Jun 27, 2018
23. HashUnlimited referenced this in commit e0781066d7 on Sep 6, 2018
24. lionello referenced this in commit 4652b62c31 on Nov 7, 2018
25. joemphilips referenced this in commit 9e01008f83 on Nov 9, 2018
26. UdjinM6 referenced this in commit 96cc2f82c2 on May 21, 2021
27. UdjinM6 referenced this in commit 0ee876f5f2 on May 21, 2021
28. UdjinM6 referenced this in commit c0c2c32571 on May 21, 2021
29. UdjinM6 referenced this in commit dddd5c7f06 on May 22, 2021
30. kittywhiskers referenced this in commit a83681afe5 on May 25, 2021
31. MarcoFalke locked this on Sep 8, 2021

Contributors
jamesob ryanofsky laanwj

Labels
GUI