API calls for getting "sending" labels and addresses #3576

As far as I can tell, right now with the API, there is a way to list (only) our own accounts/labels (listaccounts) and any addresses, given we have the account-name/label (getaddressesbyaccount). It seems like we should also be able to easily list accounts/labels belonging to "sending" addresses. An application accessing this API has no way to get at these currently, short of either linking to BDB or writing a makeshift parser for the wallet.dat (neither of which solve the problem of getting this data from a remote server).

This PR adds one API call: listsendingaddresses. It returns an object containing all labels+addresses that return false for IsMine(). It would be just as effective to return an array containing just the labels, but I thought this mirrored listaccounts nicely as an object.

$ bitcoind listaccounts
{
    "" : 0.00000000,
    "primary" : 0.00000000
}
$ bitcoind listsendingaddresses
{
    "foobar" : "1Mggntit5x2xbWeSHAJewJ4gzSnSgx4LLe",
    "foobar2" : "1QFwNG5y7CN57nBWkctU5oLQkLbA1w2BdR"
}
$ bitcoind getaddressesbyaccount foobar2
[
    "1QFwNG5y7CN57nBWkctU5oLQkLbA1w2BdR"
]

bitcoind doesn't really have the sending address book functionality that Bitcoin-Qt does, and in fact uses labels entirely differently, so I'm not sure this makes sense for it :(

@luke-jr, yeah, I understand, but the wallet itself has the capacity to contain addresses and labels(/accounts) that don't belong to the owner of the wallet. Would it be that awkward to include it in the api? Applications that use bitcoind could still make use of this.

I'm new to bitcoin dev. I realize this has probably been discussed before and may have been explicitly excluded for a reason, but maybe we can have a discussion about it.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/0cb8f2deaf33c1812bd358be98bac1626d16589c for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

It'd be consistent for sending addresses, but then inconsistent for receiving.. Bitcoin-Qt has labels for those, but bitcoind uses the same data for accounts. :/

Right. I see now. The account names can overlap. That's tough.

Maybe something more lowlevel like listalladdresses (which would simply dump every address contained in the wallet) could be useful.

I'm ashamed to say, currently, the way I deal with this in my own application is to parse the wallet.dat for anything that looks like a bitcoin address and run getaccount on all of them. If the getaccount returns an account name which is not listed in listaccounts, it's considered a "sending" address. This is a disgusting workaround, and it requires access to the wallet.dat. I designed the api call in this PR for my own needs, but maybe it would be better to have something like listalladdresses which doesn't assume any kind of intent and wouldn't necessarily run into the account name overlapping issues. Then again, I can't really think of any other use cases to argue in favor its existence.

What use case is there for this anyway? It makes sense if it's shown on the transaction, but once you've sent it, no point storing the address separately...

Disregarding the sending/receiving address inconsistencies you just pointed out, someone who prefers using the cli to manage their bitcoins might find it useful.

A cli bitcoin user might be inclined to maintain an address book for their sending addresses:

bitcoind setaccount [address] my-friend
# later ...
address=$(bitcoind getaddressesbyaccount my-friend | sed -n 2p | sed 's/[ ",]//g')
bitcoind sendtoaddress "$address" 0.5

All of the above is perfectly possible with the current API, but maybe the user doesn't remember a particular label/account-name: something like listsendingaddresses could give them a birds-eye view of all of their potential recipients. Applications/wallets using bitcoind as a backend to display all addresses would also find this useful.

Anyway, I didn't realize the account name inconsistencies when I posted this. Thanks for the input.

You're aware you should only send to an address once ever, right? So your my-friend wouldn't work very well in practice...

@luke-jr this is completely reasonable from a security perspective as you should in theory, never receive from more than one address. But in practical use, people don't change their address EVERY time and if they don't care about the MORE apparent visibility then why does it matter?

My argument here is that its not a huge change but gives a HUGE UX improvement for some bitcoin clients. If there is some other way this can be done that is "cleaner" that would be awesome as you have already mentioned, Bitcoin-QT already has this type of functionality in some way.

I'd just love to see this merged as I know it would save a lot of people some pain :).

I wonder if when we merge RIIs, if rethinking the address book would be a good idea concurrently.

@luke-jr is right: the label/account system is messed up due to historical reasons. This further confuses them.

bitcoind has accounts, bitcoin-qt has labels. There is no way to have it vice versa. This would require changes to the storage format as well as the wallet API that no one is planning to do.

But even without this conflict the account system has many properties that people find.. unexpected atleast. Everyone expects a different thing from it, it appears, it's a bit of a layering violation to have it in bitcoind in the first place.

If you have a multi-user site I must recommend to make account (internal ledger) functionality yourself as a layer on top so you can implement it in the way that you expect. If you need something that maps addresses to users, keep your own database. Do not use bitcoind accounts.

A future wallet redesign will likely not have per-address labels or accounts at all (at least not accounts in the current ledger sense, maybe subwallets consisting of deterministic address 'streams' that BIP-0032 calls accounts).

Edit: but apart from my critic on direction, the code changes look ok

Taint colored barns???

On Jan 23, 2014 12:15 AM, Luke-Jr notifications@github.com wrote:

What use case is there for this anyway? It makes sense if it's shown on the transaction, but once you've sent it, no point storing the address separately...

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/pull/3576#issuecomment-33097801.

Closing this for now.

In principle, making the labeling from Bitcoin-Qt accessible from the RPC API is a nice aim and I want to have this eventually. However, as long as we have the crappy account system that interferes with the labels (see #3816), this would further muddle the waters.