rpcclient: listaccounts is deprecated and replaced with listlabels

[brandonpille]

A couple of commands have been deprecated and replaced by others. For example listaccounts is now listlabels. Most accounts related rpcs are now renamed to label. See https://chainquery.com/bitcoin-cli

[brandonpille]

Can anyone pick this up?

[roy9495]

Hi, I want to contribute. But I don't know what code changes I have to make. Can you please elaborate on this issue?

[roy9495]

So these are the commands that got deprecated https://chainquery.com/bitcoin-cli#deprecated. Do you want all occurrences of these commands replaced by the alternatives, in this repo?
Thanks.

[brandonpille]

Yes, it doesn't make sense to use deprecated calls by default as they will disappear some day. Or at least do the same as in the bitcoin nodes. In the new bitcoin node you can pass an argument telling the node to use the old (deprecated) calls instead. I think it makes sense to do that. We should, by default, use new calls and if wanted use the deprecated calls.

[brandonpille]

Hi, do we have an estimate for this?

[brandonpille]

If someone wants to contribute, it's just modifying some function names and some arguments. Here are the required changes (got that from bitcoin repository: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#label-and-account-apis-for-wallet):

Deprecated Method	New Method	Notes
getaccount	getaddressinfo	getaddressinfo returns a json object with address information instead of just the name of the account as a string.
getaccountaddress	n/a	There is no replacement for getaccountaddress since labels do not have an associated receive address.
getaddressesbyaccount	getaddressesbylabel	getaddressesbylabel returns a json object with the addresses as keys, instead of a list of strings.
getreceivedbyaccount	getreceivedbylabel	no change in behavior
listaccounts	listlabels	listlabels does not return a balance or accept minconf and watchonly arguments.
listreceivedbyaccount	listreceivedbylabel	Both methods return new label fields, along with account fields for backward compatibility.
move	n/a	no replacement
sendfrom	n/a	no replacement
setaccount	setlabel	Both methods now: allow assigning labels to any address, instead of raising an error if the address is not receiving address. delete the previous label associated with an address when the final address using that label is reassigned to a different label, instead of making an implicit getaccountaddress call to ensure the previous label still has a receiving address.

Changed Method	Notes
addmultisigaddress	Renamed account named parameter to label. Still accepts account for backward compatibility if running with '-deprecatedrpc=accounts'.
getnewaddress	Renamed account named parameter to label. Still accepts account for backward compatibility. if running with '-deprecatedrpc=accounts'
listunspent	Returns new label fields. account field will be returned for backward compatibility if running with '-deprecatedrpc=accounts'
sendmany	The account named parameter has been renamed to dummy. If provided, the dummy parameter must be set to the empty string, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
listtransactions	The account named parameter has been renamed to dummy. If provided, the dummy parameter must be set to the string *, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
getbalance	account, minconf and include_watchonly parameters are deprecated, and can only be used if running with '-deprecatedrpc=accounts'

[elnosh]

Hi, I'm new here and looking to contribute. May I pick this up?

[Eoous]

Hi, maybe we can work together.

[yemmyharry]

@brandonpille pls is this issue still unresolved? Would love to contribute.

[joseguru]

@brandonpille pls is this issue still unresolved? Would love to contribute.

@yemmyharry If its still unresolved I would also want to help

[Roasbeef]

See #1934 also

[dv29]

is this still valid and open? i can take it up

[Roasbeef]

@dv29 yep, also see #1934

[dv29]

@Roasbeef i'm not sure how #1934 relates to this? are you saying that I should also implement the generic interface?
could you expand a little on it please? i can also work on #1934 if thats supposed to be done before this

[Roasbeef]

@dv29 what I'm saying is that we no longer strive to keep 1:1 compatibility with bitcoind, as their RPC interface changes rather frequently, and the feature sets no longer align 1:1.

The rpcclient package supports making raw requests: https://pkg.go.dev/github.com/btcsuite/btcd/rpcclient#Client.RawRequest. Using this, you can make the JSON struct in a package, then use the linked API call to make requests with that new message. The issue I linked to is about creating a more generalized way to do custom messages.

[dv29]

That makes sense, in that case i'll implement this and then work on creating the generalized way to do custom messages.