Expose GUI labels in RPC as comments #5574
Conversation
|
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. |
|
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. |
|
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. |
|
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. |
|
+1 for a consistent term between GUI and core. |
|
Need rebase(and comment addressed, probably) |
|
ut ACK, once feedback is addressed |
|
Ping @luke-jr |
|
concept ACK, will review on rebase |
|
Rebased and renamed to "label" (although I think we'll regret that). |
| @@ -1182,6 +1182,8 @@ UniValue ListReceived(const UniValue& params, bool fByAccounts) | |||
| obj.push_back(Pair("account", strAccount)); | |||
| obj.push_back(Pair("amount", ValueFromAmount(nAmount))); | |||
| obj.push_back(Pair("confirmations", (nConf == std::numeric_limits<int>::max() ? 0 : nConf))); | |||
| if (!fByAccounts) | |||
There was a problem hiding this comment.
What is fByAccounts representing here?
|
utACK |
| @@ -1235,7 +1237,8 @@ UniValue listreceivedbyaddress(const UniValue& params, bool fHelp) | |||
| " \"address\" : \"receivingaddress\", (string) The receiving address\n" | |||
| " \"account\" : \"accountname\", (string) DEPRECATED. The account of the receiving address. The default account is \"\".\n" | |||
| " \"amount\" : x.xxx, (numeric) The total amount in " + CURRENCY_UNIT + " received by the address\n" | |||
| " \"confirmations\" : n (numeric) The number of confirmations of the most recent transaction included\n" | |||
| " \"confirmations\" : n, (numeric) The number of confirmations of the most recent transaction included\n" | |||
| " \"label\" : \"label\" (string) A comment for the address/transaction, if any\n" | |||
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
An address and a transaction are essentially the same thing.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
There is no need to be distinct across an unsupported use-case. That would just encourage people to do it more often.
|
Tested ACK (fd55571) (mind the help text nit).
|
fd55571 wallet: Expose GUI labels in RPC (Luke Dashjr)
Github-Pull: bitcoin#5574 Rebased-From: fd55571
No description provided.