[RFC] Explicit UTXO Selection in z_sendmany for Greater Control

Technology zcashd client
3

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 or minconf fields because you would have two separate steps: one API to get the UTXOs corresponding to a fromaddress and matching a desired minconf, 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.
2 Likes