btcsuite
add gRPC binding for rpc method listreceivedbyaddress
listreceivedbyaddress was already present in the rpc handlers.
I added the gRPC bindings and the ReceivedForAddress to the walletServer to make the call accessible.
Hmmm not sure about the data race failure and if I really introduced that 🤔
I actually never found this RPC particularly useful. Can you describe why you want it and what problem it solves? Generally we want to shy away from APIs that work on addresses directly and instead do things on the account level.
My scenario is the following: Users sign up on the platform and can upgrade their membership. We want to offer a new address for each payment. The transaction is then associated with one specific payment address. To figure out if that transaction is fully paid, I have to retrieve the received funds for that specific address. Is the intended way to create an account for each single transaction and then retrieve one address for this one? What would be the purposes to have multiple addresses per account but only be able to retrieve the total funds for that account? Splitting one payment to multiple addresses?
Well our preferred method of querying any kind of balances is done at the account level, not on an individual address basis. This is done to avoid a common misconception in Bitcoin that addresses themselves have balances.
Have you tried creating a new account for each received payment? (or is this too restricting because you need to have all received funds in a single account since we disallow creating transactions that spend from several accounts?)
I have a concern with making the API operate at the address level rather than on accounts, since it means any optimizations we do to make an operation on an account quicker can't be taken advantage of for APIs that query info about only an address.
I'm beginning to wonder whether our account system is too restrictive. While the mapping of accounts to BIP0044 key series is a simple to understand concept and can make recovering accounts easier when restoring from a seed, it seems to cause other workflow issues with the ways that we want people using accounts for accounting rather than managing addresses directly.
@jrick "I'm beginning to wonder whether our account system is too restrictive."
The account system, as well as the API as a whole, in both bitcoind and btcwallet is an unusable disaster.
Any non-trivial application user of the API has to basically keep their own database to track individual UTXOs and replicate in business logic what a better wallet ought to be able to do for them.
I don't really blame you guys for this since you're mostly dealing with what an API design you inherited from Core, but I just wanted to get that off my chest.
@justusranvier we obviously know about the API issues, and that's why we created an entirely new API without those legacy issues. It is another reason i'm hesitant to get behind this change.
Now that some of the "bad" functionality is no longer available in the new API, we're seeing limitations to some of our core structures and ideas on how the wallet should operate. Making any major changes to these could be very disruptive not just in code but also to the users of the API, and depending on how much is changed I don't know that we can make it work with the legacy JSON-RPC API at all. I don't know what is the best way forward here.
I think the two biggest customers of a wallet API are:
- exchanges
- payment processors / merchants
Most things that people want to do with an API are either trivial or else subsets of those two use cases.
Exchanges want things like:
- Deposit instructions for users.
- When an incoming transaction is received, which user should be notified of a pending deposit?
- When can a user be safely credited for an incoming transaction?
- How much is an outgoing transaction going to cost? (before initiating the transaction)
- How much did an outgoing transaction actually cost? (after initiating the transaction)
Payment processors want things like:
- Payment instructions for customers to pay a specific invoice.
- When has a particular invoice been paid in full? (should account for normal B2B practices like using n transactions to pay m invoices)
- Refund a canceled order / incomplete payment / excessive payment.
If I was specifying a new API, I'd focus on making life easier for users with those problems and forget entirely about compatibility with the old JSON-RPC.
Not a bad list. Mind opening up a new issue with them? (we've gone a bit off topic and we don't want this list "lost" when the PR is closed)
I copied the list to this issue: https://github.com/btcsuite/btcwallet/issues/472