I think that this kind of API is a good idea, but shoe-horning explicit UTXO selection into z_sendmany
is probably not the right way to approach this. The provided outputs-to-spend-from would need to be consistent with all of fromaddress
, minconf
, fee
, and privacyPolicy
; expecting the caller to get all of this right makes for a complex API.
The proposed patch avoids these complexities by not actually implementing explicit UTXO selection. Instead, the new argument is a filter that limits the outputs z_sendmany
can select from; z_sendmany
is the final arbiter on which outputs are selected. The user can set the filter to precisely which outputs they want selected with no excess, but that would re-encounter the complexity mentioned above.
Now, if what is actually wanted here is just a filter, then this seems like a potentially reasonable change. However, the changes would actually need to be implemented in Zallet, which is replacing the zcashd
wallet (and currently does not even have z_sendmany
implemented).
But for explicit UTXO selection, I think a more forward-compatible approach here would be to lean into transaction proposals and PCZTs, for several reasons:
- Selecting outputs to add as spends for a PCZT is precisely what the Constructor role in a PCZT workflow does. A JSON-RPC equivalent to that role makes perfect sense.
- There’s no conflict with
fromaddress
orminconf
fields because you would have two separate steps: one API to get the UTXOs corresponding to afromaddress
and matching a desiredminconf
, and then a separate API taking the explicitly-chosen UTXOs without either of the fields. - There’s no conflict with a
fee
field because fee-handling would be reversed. Instead of setting an explicit fee, the APIs would return an error if there were insufficient inputs to construct the desired transaction with a ZIP 317 fee, and then you’d explicitly select more UTXOs to make up the difference.- Having to iterate multiple times on this is part of why explicit UTXO selection can be very complex, and may be one reason to actually prefer a filter API depending on whether that actually serves the desired use case.
- There’s no conflict with a
privacyPolicy
field because this is also inverted. Per my other comment, with a proposal / PCZT workflow you instead have the wallet propose a transaction, that the caller can inspect to determine its privacy properties and whether they are desirable.