Not titled “raw shielded transactions”, because I need all three cases: z→z, z→t, t→z.
Is there a documented, non-deprecated way, not being removed, to generate a raw transaction involving z-addresses, or at least split transaction generation and broadcast into seperate explicit operations?
I am reluctant to risk money on an API such as zcrawjoinsplit which is poorly documented, deprecated, “might be removed at any time” (said @daira), and possibly not receiving the sort of maintenance attention which prevents money-losing bugs.
Given the current time and memory requirements for a JoinSplit, there are all sorts of potential use cases for generating a z-transaction and then broadcasting it later:
-
Pre-generating a transaction for a recipient who has a time limit for sending a transaction. Most time limits are 10 minutes, but I have seen as short as 100 seconds. Now, remember that a z-transaction can sometimes require multiple JoinSplits… Means to shift latency could be really useful!
-
Pre-generating transactions on a laptop with only 4–8 GiB total RAM, where
zcashdhogs the machine during proof generation, and then starting software (such as a web browser) which may be useful for actually engaging in business activity. -
Pre-generating transactions at time of low server load, when they are expected to be needed at time of high server load; or generating a bunch of transactions slowly, when it is expected they will be needed all at once. For example, payroll software which cuts Z-paychecks could generate proofs at night or all week, then broadcast the resulting transactions on Z-payday.
-
Generating a transaction on a more trusted machine which has the private keys, then sending it from a less trusted machine which is online. (TODO: Figure out how to move blockchain data across airgap. TODO: Code an anonymous transaction distribution network involving carrier pigeons. Really, separating proof generation from network broadcast is just cleaner and more useful.)
I don’t really want to say what my use case is, but it is some conceptual combination of the above. <g>
If the Zcash team really wants cover all reasonable functionality with improvements to z_sendmany, then perhaps a version of that RPC call which generates the transaction and returns it as a string would be good. (Combined with another call which takes the string, and broadcasts it to the network.) But also, I am looking for something which could be used reliably right now, on 1.0.12.
Thanks!