This implements 2 features:

1. Allowing the user to view all webcash secrets in their wallet in a clean manner
2. Allowing a user to pay from a specific webcash secret

At some point perhaps Webcasa.app can allow a user to click on the secret they wish to spend from, via a checkbox list.

Mining can cause a wallet to become quite bloated with outputs. This PR adds a merge command that can be used to merge outputs together in batches, to consolidate the webcash of the wallet into a small number of outputs. The status command is also updated to show the current number of outputs.

What the title says. Any invalid secret values are moved to the "unconfirmed" field of the wallet as a safety measure, at least until this command is thoroughly tested.

We can nearly double the speed of the official Python miner without too much complication by not regenerating secrets after an unsuccessful attempt. This does require that we submit a nonce to differentiate the attempts, however. Thankfully the mining server seems to be liberal in what it accepts.

(This is the same technique used by maaku/webminer)

There's no difference between 3.4.2 (latest) and 3.4.1, except availability on older python versions, such as Python 3.6 which is used on Ubuntu 18.04 LTS. Downgrading this dependency version gets us working out of the box on more platforms.

Save "unconfirmed" webcash to the wallet before a "replace" API call, so that funds are not irrevocably lost if there is a network error during the communication with the server.

There is no code here to recover funds. We are just making sure that the wallet file remembers any keys used during a failed operation, so that they can be later recovered if necessary.

Partial fix for issue #1.

If the server times out or the network connection is disconnected while performing a replacement, it is possible that the action is still performed by the server even though a confirmation was not received by the client. In such cases the requests python module will error out, which causes the whole operation to be cancelled, and the new ephemeral key is thrown away.

This combination of events, which has happened during recent server overloads, results in certain loss of funds. Although switching to deterministic wallets will mitigate the worst aspects of this problem, a stopgap measure is still needed before then to protect user funds.

Probably the easiest solution is to save the wallet with a "unconfirmed" array of webcash secrets just prior to making the replace API call. Should a wallet later be opened with this field populated, the secrets should be run though the health check API to see if the transaction went through.

Does it make sense to auto-sort webcash secrets in the wallet? This mimics real life behaviour where you use up small denoms for any transaction before dipping into bigger denoms. Currently the wallet searches for exact value or consolidates top of stack, irrespective of value.

I have an implementation and PR available to be merged.

This implements 2 features:

Allowing the user to view all webcash secrets in their wallet in a clean manner
Allowing a user to pay from a specific webcash secret

At some point perhaps Webcasa.app can allow a user to click on the secret they wish to spend from, via a checkbox list.

If the reported wallet depth in the wallet is one less than the actual walletdepth, the recovery code did not fix it. This commit commit fixes that off-by-1 error.