Expose GUI labels in RPC as comments #5574

luke-jr commented at 2:13 PM on December 30, 2014: member

No description provided.

jgarzik added the label RPC on Dec 30, 2014

jgarzik added the label Wallet on Dec 30, 2014

laanwj commented at 8:54 AM on December 31, 2014: member

I'm not opposed to adding this information, but won't this confuse GUI labels and RPC accounts further? Right now these collide, so people should either use the GUI with labels or RPC with (or without) accounts.

luke-jr commented at 9:09 AM on December 31, 2014: member

If we're going to deprecate accounts, IMO we should add support for labels first. It doesn't increase the conflict, since the GUI already supports accounts via RPC and the debug window. This just makes it possible to access the GUI-only information from bitcoind as well.

laanwj commented at 12:35 PM on January 29, 2015: member

I think then we should simply call it 'label', or 'address label'. Any API replacing the account system would use that for consistency with the GUI.

laanwj commented at 8:23 AM on June 10, 2015: member

Needs rebase. And I still think the string should have the same name as in the GUI, e.g. 'label', introducing a new term 'comment' will just cause confusion.

Diapolo commented at 11:44 AM on June 15, 2015: none

+1 for a consistent term between GUI and core.

laanwj commented at 10:34 AM on July 21, 2015: member

Need rebase(and comment addressed, probably)

jgarzik commented at 6:49 PM on July 23, 2015: contributor

ut ACK, once feedback is addressed

jgarzik commented at 4:17 PM on September 15, 2015: contributor

Ping @luke-jr

dcousens commented at 7:03 AM on September 16, 2015: contributor

concept ACK, will review on rebase

luke-jr force-pushed on Oct 2, 2015

wallet: Expose GUI labels in RPC fd55571f06

luke-jr force-pushed on Oct 2, 2015

luke-jr commented at 12:22 AM on October 2, 2015: member

Rebased and renamed to "label" (although I think we'll regret that).

in src/wallet/rpcwallet.cpp:None in fd55571f06

1181 | @@ -1182,6 +1182,8 @@ UniValue ListReceived(const UniValue& params, bool fByAccounts)
1182 |              obj.push_back(Pair("account",       strAccount));
1183 |              obj.push_back(Pair("amount",        ValueFromAmount(nAmount)));
1184 |              obj.push_back(Pair("confirmations", (nConf == std::numeric_limits<int>::max() ? 0 : nConf)));
1185 | +            if (!fByAccounts)

dcousens commented at 1:31 AM on October 2, 2015:

What is fByAccounts representing here?

laanwj commented at 8:17 AM on October 2, 2015:

listreceivedbyaccount

dcousens commented at 1:32 AM on October 2, 2015: contributor

utACK

in src/wallet/rpcwallet.cpp:None in fd55571f06

1236 | @@ -1235,7 +1237,8 @@ UniValue listreceivedbyaddress(const UniValue& params, bool fHelp)
1237 |              "    \"address\" : \"receivingaddress\",  (string) The receiving address\n"
1238 |              "    \"account\" : \"accountname\",       (string) DEPRECATED. The account of the receiving address. The default account is \"\".\n"
1239 |              "    \"amount\" : x.xxx,                  (numeric) The total amount in " + CURRENCY_UNIT + " received by the address\n"
1240 | -            "    \"confirmations\" : n                (numeric) The number of confirmations of the most recent transaction included\n"
1241 | +            "    \"confirmations\" : n,               (numeric) The number of confirmations of the most recent transaction included\n"
1242 | +            "    \"label\" : \"label\"                (string) A comment for the address/transaction, if any\n"

jonasschnelli commented at 8:32 AM on October 2, 2015:

Hmm... i think we should not use "transaction" as entity where a label is stored. What about just using (string) A comment for the address, if any\n"?

luke-jr commented at 9:26 PM on October 2, 2015:

An address and a transaction are essentially the same thing.

jonasschnelli commented at 12:39 PM on October 5, 2015:

An address and a transaction are essentially the same thing. ^^ Not that I like address re-using: But there are use cases (and users-behaviors) where multiple transactions having outputs to the same address. How could you distinct between these transactions over labels/comments if we would say address==transaction?

We have the term "Address" book where every address has one label. Maybe in future, the Addressbook has identities which could create a payment address over BIP70 or BIP32.

For now i think there are reasons to label/comment an address as well as a transaction.

luke-jr commented at 4:44 PM on October 5, 2015:

There is no need to be distinct across an unsupported use-case. That would just encourage people to do it more often.

jonasschnelli commented at 8:50 AM on October 2, 2015: contributor

Tested ACK (fd55571f069640fc2733410061e82b8dd2ed9280) (mind the help text nit).

laanwj merged this on Nov 10, 2015

laanwj closed this on Nov 10, 2015

laanwj referenced this in commit 755b4ba848 on Nov 10, 2015

luke-jr referenced this in commit 0b510220fc on Nov 27, 2015

DrahtBot locked this on Sep 8, 2021