Skip to content
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

Add z_sendfromaccount method to supersede z_sendmany #6123

Open
nuttycom opened this issue Aug 19, 2022 · 9 comments
Open

Add z_sendfromaccount method to supersede z_sendmany #6123

nuttycom opened this issue Aug 19, 2022 · 9 comments
Assignees
Labels
A-rpc-interface Area: RPC interface
Milestone

Comments

@nuttycom
Copy link
Contributor

nuttycom commented Aug 19, 2022

The API of z_sendmany is no longer appropriate when using unified addresses; it misleads people to think that unified addresses can represent distinct pools of funds (and perpetuates a similar problem related to spending from legacy transparent addresses, see #6113.). Adding, z_sendfromaccount will help clarify this usage.

z_sendfromaccount should take the following arguments:

fromAccount [{\"address\":... ,\"amount\":...},...] ( minconf ) ( fee ) ( privacyPolicy )

It should follow the pattern of z_sendmany, but accept an integer account ID instead of an address as the source of funds. z_sendfromaccount should perform opportunistic shielding when permitted by the privacy policy: if there are any shielded recipients, all transparent UTXOs available within the account should be spent, with change being sent to the account's internal change address.

An alternative is to overload the fromaddress field of the z_sendmany call to default to parsing its value as an account identifier if parsing an address fails, but perhaps we shouldn't have added unified address parsing (in favor of parsing as an account ID) in the first place.

@nuttycom
Copy link
Contributor Author

After z_sendfromaccount is introduced, z_sendmany should be modified to deprecate unified address parsing.

@gesker
Copy link

gesker commented Aug 20, 2022

Which address will be used if the account has multiple addresses? I.e. z_getaddressforaccount has been called on an account more than once?

First, last, random?

Or, an optional parameter to specify the UA within the account on the z_sendfromaccount?

Maybe a corresponding helper method (e.g. z_sendFromUaAddressOrSomething) that will just take an UA address and determine which account the address belongs to if the address belongs to your wallet -- the wallet having had z_getnewaccount called a number of times in conjunction with z_getaddressforaccount also being called a number of times for each account?

@nuttycom
Copy link
Contributor Author

nuttycom commented Aug 20, 2022 via email

@gesker
Copy link

gesker commented Aug 21, 2022 via email

@gesker
Copy link

gesker commented Aug 21, 2022 via email

@nuttycom
Copy link
Contributor Author

Is an integer (account number) or string (address) passed the the new method? Or, both? Use this address from this account?

Oops, I think I got confused about what thread I was responding to. Within a single account, there is no distinction between the different addresses; the account is treated as a single source of funds, and which (diversified) address funds were received on is not tracked, so to implement z_sendfromaccount the account ID should be an integer argument.

@gesker
Copy link

gesker commented Sep 24, 2022

if z_getaddressforaccount is called twice on an account which address does the recipient see when funds are sent using z_sendfromaccount?

@nuttycom
Copy link
Contributor Author

if z_getaddressforaccount is called twice on an account which address does the recipient see when funds are sent using z_sendfromaccount?

@gesker The recipient never sees the sender's address under any circumstances (unless the sender manually includes their address in the memo field or something), so I'm not sure I understand this question.

@gesker
Copy link

gesker commented Mar 17, 2023

Thank @nuttycom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc-interface Area: RPC interface
Projects
None yet
Development

No branches or pull requests

5 participants