RPCWallet: Notate all account stuff as deprecated

luke-jr commented at 2:32 pm on December 30, 2014: member

luke-jr force-pushed on Dec 30, 2014

RPCWallet: Notate all account stuff as deprecated 7b782f5b01

luke-jr force-pushed on Dec 30, 2014

jgarzik added the label RPC on Dec 30, 2014

jgarzik added the label Wallet on Dec 30, 2014

petertodd commented at 4:53 am on January 3, 2015: contributor

utACK

laanwj commented at 9:56 am on January 3, 2015: member

ut ACK

fanquake commented at 9:57 am on January 3, 2015: member

utACK

jtimon commented at 2:23 pm on January 3, 2015: contributor

ACK

sipa commented at 3:23 pm on January 4, 2015: member

I have an alternative suggestion here, namely to ‘degrade’ accounts back into labels. That means marking all RPC methods that operate on the concept of an “account balance” as deprecated, but not the ability to list transactions received with a particular label etc.

Pro: address labels already exist in the GUI and we probably want to keep them there, so making the RPC functionality analogous should be easy, and it doesn’t have the potential confusion risk that accounts have. Cons: If we’re going to break functionality, maybe it should be broken entirely.

jgarzik commented at 3:39 pm on January 4, 2015: contributor

@sipa That was my suggestion months ago in IRC: Adding one or more “tags” to each address is still useful.

luke-jr commented at 3:42 pm on January 4, 2015: member

@sipa That may not be as simple as you think - GUI labels and accounts overlap only for receive transactions. Send transaction labels and send account are entirely unrelated right now. :/

laanwj commented at 8:04 am on January 5, 2015: member

I like sipa’s idea. The labels feature is useful, and aiming to expose it eventually in both RPC and the GUI would make things symmetrical, which is what many users expect.

On the other hand doing that without confusing current users of accounts even more will be difficult. Hence I like first communicating a complete deprecation of the account system as in this pull.

Then introduce a new API for labels. This also makes it clear that the label system is separately useful and not just ‘degraded accounts’. The usual warning apply - “don’t use this at the same time as the account system, or it will get confused”.

laanwj commented at 9:34 am on January 8, 2015: member

That means marking all RPC methods that operate on the concept of an “account balance” as deprecated, but not the ability to list transactions received with a particular label etc.

As there would no longer be a concept of ‘account address’ or ‘account balance’ the label API could be very minimal, e.g.:

getaddressesforlabel [like getaddressesforaccount]
listlabels [like listaccounts, but would just return a list of labels, without balances - and would need an argument to filter for sending/receiving labels]
setlabel (address, label) [like setaccount, but also allows setting labels for sending addresses]

These would stay the same, and accept a label instead of an account:

getnewaddress (label)
listtransactions (label,…)

Others, like sendfrom would no longer make sense at all, eg. there is no point in sending from a label.

laanwj referenced this in commit e2677d7ae8 on Jan 8, 2015

luke-jr commented at 12:17 pm on January 8, 2015: member

Note: BFGMiner needs some equivalent of getaccountaddress.

It would make sense to let sendfrom (or at least sendmany) set a label for a send, to avoid having to make 2 RPC calls for each send.

laanwj commented at 12:22 pm on January 8, 2015: member

What would be the point of getaccountaddress without accounts? Why not use getnewaddress (label)?

Re: sendfrom, fine, but then rename it and get rid of the from and call it sendandlabel or such… But IMO we have too many send functions already :/ In principle we could do with just sendmany.

luke-jr commented at 12:28 pm on January 8, 2015: member

getnewaddress always creates a new address. In the case of mining, you want to continue to use the same one you were using last time until you find a block. I believe this goes for P2Pool as well.

sendmany-only sounds fine to me.

laanwj commented at 12:39 pm on January 8, 2015: member

Couldn’t you use getaddressesforlabel then, and if no results, get a new address? Alternatively, remember the last-used address internally.

luke-jr commented at 12:41 pm on January 8, 2015: member

getaddressesforlabel doesn’t tell you if addresses are used or not, does it? At this time, there is no internal storage of any sort… hate to add it for this.

laanwj commented at 12:44 pm on January 8, 2015: member

Well, the concept of a ’label address’ just doesn’t make sense, and also has no GUI equivalent.

Also there is some weird interaction that prevents the last address from being moved from an account, and that interaction has to do with the ‘account address’. To make it work like GUI labels (so you can get rid of them by renaming), that would have to be changed as well. Easiest would be to just get rid of the confusing feature.

luke-jr commented at 12:53 pm on January 8, 2015: member

“Get unused address with label” makes sense - albeit only for mining (since bitcoind won’t know if it’s used-but-not-broadcast-yet). Maybe “getminingaddress” would be appropriate?

laanwj merged this on Jan 26, 2015

laanwj closed this on Jan 26, 2015

laanwj referenced this in commit 2511a39cca on Jan 26, 2015

Fuzzbawls referenced this in commit 73d331a9dd on Jan 10, 2020

random-zebra referenced this in commit 441d790d8c on Jan 11, 2020

Fuzzbawls referenced this in commit d2098972dc on Jan 11, 2020

Liquid369 referenced this in commit c7103068df on Jan 16, 2020

reddink referenced this in commit f7eaa7c82f on May 27, 2020

wqking referenced this in commit 18bea585f2 on Jun 5, 2020

MarcoFalke locked this on Sep 8, 2021

RPCWallet: Notate all account stuff as deprecated #5575