Raw Proof Generation for JoinSplits/z-transactions

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 zcashd hogs 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.


You might find they payment offloading work relevant to this: https://github.com/zcash/zcash/projects/5

This feature will allow under-resourced clients to offload the joinsplit operation to a more capable server.