New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPCWallet: Notate all account stuff as deprecated #5575

Merged
merged 1 commit into from Jan 26, 2015

Conversation

Projects
None yet
7 participants
@luke-jr
Member

luke-jr commented Dec 30, 2014

No description provided.

@luke-jr luke-jr force-pushed the luke-jr:accts_deprecate branch Dec 30, 2014

@luke-jr luke-jr force-pushed the luke-jr:accts_deprecate branch to 7b782f5 Dec 30, 2014

@petertodd

This comment has been minimized.

Contributor

petertodd commented Jan 3, 2015

utACK

@laanwj

This comment has been minimized.

Member

laanwj commented Jan 3, 2015

ut ACK

@fanquake

This comment has been minimized.

Member

fanquake commented Jan 3, 2015

utACK

@jtimon

This comment has been minimized.

Member

jtimon commented Jan 3, 2015

ACK

@sipa

This comment has been minimized.

Member

sipa commented Jan 4, 2015

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

This comment has been minimized.

Contributor

jgarzik commented Jan 4, 2015

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

@luke-jr

This comment has been minimized.

Member

luke-jr commented Jan 4, 2015

@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

This comment has been minimized.

Member

laanwj commented Jan 5, 2015

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

This comment has been minimized.

Member

laanwj commented Jan 8, 2015

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 added a commit that referenced this pull request Jan 8, 2015

@luke-jr

This comment has been minimized.

Member

luke-jr commented Jan 8, 2015

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

This comment has been minimized.

Member

laanwj commented Jan 8, 2015

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

This comment has been minimized.

Member

luke-jr commented Jan 8, 2015

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

This comment has been minimized.

Member

laanwj commented Jan 8, 2015

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

@luke-jr

This comment has been minimized.

Member

luke-jr commented Jan 8, 2015

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

This comment has been minimized.

Member

laanwj commented Jan 8, 2015

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

This comment has been minimized.

Member

luke-jr commented Jan 8, 2015

"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 laanwj merged commit 7b782f5 into bitcoin:master Jan 26, 2015

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Jan 26, 2015

Merge pull request #5575
7b782f5 RPCWallet: Notate all account stuff as deprecated (Luke Dashjr)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment