XMLRPC: setaccount moves label to the other, unused address #1231

issue sgaltsev openend this issue on May 9, 2012
  1. sgaltsev commented at 4:22 am on May 9, 2012: none

    This is the bug that has been in client and daemon since very beginning. Intention of setaccount command is essentially to rename existing account. For some reason, from very beginning, it was reallocating old label to some other address. Can we get rid of this?

    There is no other means to rename the label using XMLRPC without creating artifacts.

    Alternatively, is it possible to introduce another XMLRPC command designed to rename label on account? I need to be able to not keep existing one.

     0Value setaccount(const Array& params, bool fHelp)
     1{
     2if (fHelp || params.size() < 1 || params.size() > 2)
     3    throw runtime_error(
     4        "setaccount <bitcoinaddress> <account>\n"
     5        "Sets the account associated with the given address.");
     6
     7CBitcoinAddress address(params[0].get_str());
     8if (!address.IsValid())
     9    throw JSONRPCError(-5, "Invalid bitcoin address");
    10
    11
    12string strAccount;
    13if (params.size() > 1)
    14    strAccount = AccountFromValue(params[1]);
    15
    16// Detect when changing the account of an address that is the 'unused current key' of another account:
    17//if (pwalletMain->mapAddressBook.count(address))
    18//{
    19//    string strOldAccount = pwalletMain->mapAddressBook[address];
    20//    if (address == GetAccountAddress(strOldAccount))
    21//        GetAccountAddress(strOldAccount, true);
    22//}
    23
    24pwalletMain->SetAddressBookName(address, strAccount);
    25
    26return Value::null;
    27}
    
  2. gavinandresen commented at 1:20 pm on May 9, 2012: contributor

    You are misunderstanding what that code does.

    Can you give a series of RPC commands that shows the bug? setaccount associates a bitcoin address with an account, it we removed the “Detect when changing…” code as you suggest then you get situations where one address is associated with TWO accounts, which is wrong.

  3. sgaltsev commented at 2:18 am on May 11, 2012: none

    Here’s series of actions to demonstrate the problem:

    1. Create address: http://vvcap.net/db/ig2jMMXnX1MTPybtAFM7.htp
    2. Now the customer paid for the item, and we want to rename account: http://vvcap.net/db/FKIoM_-Rvt4LXqBcp9a1.htp
    3. We get this: http://vvcap.net/db/go58vwdQsVlfVXqxz2N3.htp . This is the EXPECTED behavior, the one I want to reproduce using XMLRPC.
    4. I rename account back: http://vvcap.net/db/NthP4EtVkOgKaOhpkCQj.htp
    5. Now I do the same thing using bitcoind, which uses same xlmrpc: http://vvcap.net/db/kxooAA7LiRhaa0ktxOBF.htp
    6. EXPECTED: old address is replaced with “—-> 02. Customer Actually Paid” and not kept anywhere else in the address book

    On 3.x versions, after that command, I have been getting address renamed, but “—-> 01…” one relocated to a new. Same behavior I saw on another client, which I downloaded ~ 20-ish April 2012. I think it was 0.6.1, but maybe 0.6.0. According to the timestamps 0.6.1 didn’t exist at this time, so maybe I’m imagining things. I did not take screenshots, and cannot reproduce it anymore.

    I retested now on all 0.6 versions and following are results:

    0.6.0 does not rename at all 0.6.1 and 0.6.2 work as expected

    so I guess the bug is fixed. I have no idea why did I see that problem previously but not now. Since problem is not reproducibnle, I am closing the bug I guess.

  4. sgaltsev closed this on May 11, 2012

  5. sgaltsev reopened this on May 11, 2012

  6. sgaltsev commented at 2:28 am on May 11, 2012: none

    Okay, I reproduced the problem. I was apparently renaming outgoing address, when bug is affecting receiving address. Here’s how it goes:

    1. Start position: http://vvcap.net/db/MUThlEUsdjSUl1uhdqaW.htp
    2. Rename using daemon: http://vvcap.net/db/vWiLAQcDBlZc-recHldI.htp
    3. Get this: http://vvcap.net/db/9KAeMv31O700xXl91mqx.htp

    So, instead of renaming the address, setaccount relocated label to another address.

    Client version is here: http://vvcap.net/db/8SgEs2t3RfMcJ_jD7UlM.htp

  7. msva commented at 11:03 pm on May 12, 2012: contributor

    not “instead”, btw. As I see on [3] — it renamed addres fine, but also (not instead) it moved “—-> 1” to another one (does it? doesn’t you?)

    Btw, I remember something like that on very-very-very old bitcoin-qt releases, when it created new addresses every time I tried to rename existing, but than @laanwj fixed this.

    So, I guess, it is GUI-related bug (like it was on bitcoin-qt before moving it to main tree).

  8. sgaltsev commented at 5:33 pm on May 29, 2012: none

    @msva You are right. What I was trying to say is that expected behavior is that account gets renamed and nothing else. Instead of that account gets renamed AND an old label gets relocated. The code that does it is located in RPC, at function Value setaccount(const Array& params, bool fHelp), so it affects both GUI and daemon, and I saw this code in every incarnation of bitcoin client RPC.

    What makes this bug extra annoying is that essentially it makes impossible to get rid of the label once it is in the database, unless you use GUI.

    Is it possible to get this addressed anytime soon? I’m so tired of having to recompile client every time a new version comes out.

  9. laanwj commented at 4:05 pm on June 13, 2012: member

    @msva, that bug was related to the “default address” (vchDefault). Indeed, the default address is no longer used or updated when QT_GUI is set.

    The problem here is that the “account system” is slightly different from the UI labels. It doesn’t allow removing all addresses from an account, which is intended behavior not a bug. We cannot change this as programs might be relying on this.

    Maybe there should be a command to delete an account and move all its addresses to the "" label.

  10. laanwj commented at 12:20 pm on January 10, 2014: member
    We’re not going to touch the accounts for the foreseeable future. It is not even sure if the future wallet implementation will have such a feature at all. If you want anything else than the current state, it is recommended to build your own ledger system on top.
  11. laanwj closed this on Jan 10, 2014

  12. laanwj referenced this in commit 52aeffb7e4 on Mar 21, 2016
  13. laanwj referenced this in commit 4f522a6e49 on Mar 21, 2016
  14. laanwj referenced this in commit d036fa4411 on Mar 21, 2016
  15. jnewbery referenced this in commit ba8692b7d5 on Jun 12, 2017
  16. jnewbery referenced this in commit 156ead3048 on Jun 12, 2017
  17. jnewbery referenced this in commit 5b74e7e8eb on Jun 12, 2017
  18. laanwj referenced this in commit bd8708fab4 on Jun 14, 2017
  19. laanwj referenced this in commit 8571fee617 on Jun 29, 2017
  20. jnewbery referenced this in commit 86d8e115f9 on Sep 13, 2017
  21. ryanofsky referenced this in commit 90250d98e0 on Oct 21, 2017
  22. ryanofsky referenced this in commit 1dbfe49c48 on Oct 21, 2017
  23. ryanofsky referenced this in commit 7924a22a76 on Oct 21, 2017
  24. ryanofsky referenced this in commit e349abbe5e on Oct 21, 2017
  25. ryanofsky referenced this in commit b854badace on Oct 23, 2017
  26. ryanofsky referenced this in commit 5ee1c2e705 on Dec 1, 2017
  27. ryanofsky referenced this in commit 55f7b663c8 on Dec 1, 2017
  28. ryanofsky referenced this in commit a94075a424 on Jan 6, 2018
  29. ryanofsky referenced this in commit c7499fdd9f on Jan 11, 2018
  30. ryanofsky referenced this in commit a4291c5695 on Jan 17, 2018
  31. ryanofsky referenced this in commit 11c5e2d5a3 on Jan 18, 2018
  32. ryanofsky referenced this in commit c5a7f9ddeb on Jan 25, 2018
  33. ryanofsky referenced this in commit bcff61bedc on Feb 12, 2018
  34. ryanofsky referenced this in commit 55c5289acb on Mar 7, 2018
  35. ryanofsky referenced this in commit 2198ddaebd on Mar 15, 2018
  36. ryanofsky referenced this in commit dd425a0dad on Mar 19, 2018
  37. ryanofsky referenced this in commit 1141a32e91 on Mar 23, 2018
  38. ryanofsky referenced this in commit 6a0d27412d on Mar 23, 2018
  39. jnewbery referenced this in commit a8d607dda8 on Apr 5, 2018
  40. jnewbery referenced this in commit c733a983bc on Apr 5, 2018
  41. jnewbery referenced this in commit cec0de8723 on Apr 6, 2018
  42. jnewbery referenced this in commit 1f7f1dfd1c on Apr 7, 2018
  43. jnewbery referenced this in commit 0277f2dd0f on Apr 9, 2018
  44. jnewbery referenced this in commit 8bf0a96018 on Apr 9, 2018
  45. jnewbery referenced this in commit cd62be8583 on Apr 10, 2018
  46. jnewbery referenced this in commit 62cad4c90c on Apr 10, 2018
  47. jnewbery referenced this in commit 3d42c91fac on Apr 10, 2018
  48. jnewbery referenced this in commit 7222d0b8ea on Apr 10, 2018
  49. jnewbery referenced this in commit 189e0ef33e on Apr 10, 2018
  50. laanwj referenced this in commit 9b3370d1c6 on Apr 11, 2018
  51. stamhe referenced this in commit c794a93d2f on Jun 27, 2018
  52. HashUnlimited referenced this in commit 34d278812b on Sep 5, 2018
  53. lionello referenced this in commit 6ddd4c502f on Nov 7, 2018
  54. joemphilips referenced this in commit b7f1086134 on Nov 9, 2018
  55. lateminer referenced this in commit d0b63dddd9 on Jan 22, 2019
  56. lateminer referenced this in commit ccb2402d47 on Jan 10, 2020
  57. dexX7 referenced this in commit 076613f1cb on Jul 1, 2021
  58. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 00:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me