RPCWallet: Notate all account stuff as deprecated

[luke-jr]

No description provided.

[petertodd]

utACK

[laanwj]

ut ACK

[fanquake]

utACK

[jtimon]

ACK

[sipa]

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]

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

[luke-jr]

@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]

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]

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.

[luke-jr]

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]

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]

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]

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

[luke-jr]

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]

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]

"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?