Accounts - allow account merging/deletion #1894

The JSON RPC allows one to create accounts at a whim. However, there is little functionality for getting rid of old accounts.

For example, if I deal with a customer, I create an account "Order 1" to let them pay into the account. After I am done dealing with the order, I can't really get rid of the account. This way, even after many months, I would still see it in the account list, even if I don't need it.

I wouldn't want to delete the addresses associated with the account, but I would like to have an option of merging that "Order 1" account into for example "Archive" account. Currently I can only try getting that functionality by listing all addresses owned by an account and assigning them individually to a different account.

See also #1231.

There is currently no way to completely get rid of an account.

As I've proposed in the linked issue: there needs to be a RPC command that deletes an account and moves all its addresses to "".

This would need a thorough test plan, and the semantics woul dhave to be nailed down (example: what happens if I delete an account that I have 'move'd to/from or used in a 'sendfrom' ? Do those transactions get deleted from listtransactions, or are they modified? Accountants tend to get upset if history is lost or altered, so maybe that is not the right approach....)

Good point, I think we need to get clearly specified what exactly we want the account system to do in the first place, before we make it even more crazy and inconsistent by adding manipulation commands.

Hmm, good points. I guess I should look into writing some mock-up first taking those concerns into consideration.

Okay, I guess there are two similar things one could want to do with an account:

1. Rename an account This should be the easier of the two. Change the name of the account everywhere it was used - transactions, moves, balances and so forth. This would be useful when someone would for example be programming something and have to switch the naming convention mid-operation. Work only on whole accounts, not individual addresses (that is offered elsewhere). Allow for account merging this way, and "deletion", by letting people rename an account into something that is already present.

2. Archive an account Similarly as before, but upon execution the fact would be noted in the log/transaction history, and all money-related records would remain unchanged. A transaction that was sent to account X will still say it was sent to X, but the account would not be usable until it would be created again. The old addresses would be moved to a new account. This would allow users to clean up all addresses from old accounts into some "archive" account, while still keeping their transactions traceable.

I know the option 2 would require a lot more work, but I think the first one shouldn't be too hard.

Well, that's my proposal. Any thoughts?

I was looking through bitcoin issues at github for something useful that I could fix. I found "accounts - allow account merging/deletion" although it's a year old. This is basically a request for the ability to remove addresses from the wallet.

#1894

I'm thinking that this would be a good thing to implement for privacy, because it would allow people to remove addresses once they've been used. The semantic problem is that the removed addresses, although made zero-balance on command when the client deletes them, are still visible to other users of the blockchain, and somebody out there will send transactions to old addresses whose creator wants to not use those addresses any more.

In order to fully support the removal of old addresses, I think that "burn this address" needs to result in a transaction that is stored in the blockchain. It would be a transaction with that address as input and no output - forwarding any 'dust' in the address to whichever miner harvests the block. Transactions created later would be considered valid but nonstandard if they use such "burnt" addresses in any way. IE, they would not cause any client to reject them on syncing the blockchain, but "savvy" clients would neither create such transactions nor relay them.

In a later world, if it is found that 98% + of all clients making tx in the last 2016 blocks are "savvy" then the hardfork of making it into an invalid transaction could happen.

#1894 makes sense, but your commentary does not. Addresses are not accounts, and addresses are not the same thing as ECDSA keypairs. While it might make sense to remove private keys after they receive their transaction, it's dangerous and I'm not sure there's a real use case. Removing an address doesn't really make sense - other than maybe hiding it on the address list or something.

Removing an account would simply hide it from the listaccounts list.

I see a value in integrating @petertodd's dust-b-gone concept, but not so much your proposed "burn this address"; addresses do not store coins. It certainly wouldn't justify a hardfork...

We're not going to touch the accounts for the foreseeable future. It is not even sure if the future wallet implementation will have such a feature at all. If you want anything else than the current state, it is recommended to build your own ledger system on top.