Optimize download for `sapling-spend.params` and `sapling-output.params`

[ccjernigan]

Is your feature request related to a problem? Please describe.

The SDK lazily downloads sapling-spend.params and sapling-output.params when the user initiates shielded spends. This has two problems:

1. It can make first spend slow as it needs to download ~50mb (and potentially unreliable if z.cash is down but lightwalletd is up)
2. It isn't necessary for non-sapling spend (e.g. orchard)

Describe the solution you'd like

1. Download the files when sapling transactions are discovered, so that first spend of these funds is faster and more reliable
2. Don't download these files during spend if the transaction isn't sapling

[HonzaR]

Hi @str4d @nuttycom, please, may I ask you for advice on how we can recognize a sapling transaction from a non-sapling transaction? It's a necessary prerequisite for this task. Thank you.

[pacu]

I think the easiest way to do this is to check for a unverified sapling balance after finishing syncing. If so, the parameters should be ready when the funds are confirmed.

there are some nuances to this for example when user attempts to send sapling funds while downloading the parameters. The fact that the download is started the moment unverified sapling funds are detected should avoid this scenario. but it should be considered possible.

[HonzaR]

Thanks @pacu, this way it's possible, we need to play a bit with the code to be able to trigger the sapling parameters fetch from blocks sync mechanisms. And yes, a possible send action before the fetch is finished needs to wait for it.

[str4d]

Currently, all transactions received by the SDK will be Sapling transactions, either because they are received to a Sapling receiver, or are received to a transparent receiver and need to be shielded to Sapling. So for now you can just mock out the "is Sapling" check. After doing so, open an issue for "replace the mock with a real check" and we can ensure that it is hooked into the DAG for completion when we add Orchard

[HonzaR]

Thank you @str4d, we've decided to postpone this issue so we don't introduce any mocked functionality to the code base, as it's working fine now and this enhancement can therefore, wait for the orchard implementation.