Wallet restore

[altafan]

Wallet restore

This adds support for restoring a BIP44 wallet with a default or custom root path. With the cli it's enough to run ocean wallet restore --password <password> --mnemonic <mnemonic> [--root-path <path>] to restore the wallet based on the given seed. And thanks to the electrum blockchain scanner the operation is incredibly fast.

Changes

• Proto: RestoreWallet rpc has been changed from unary to server-side stream in order to send notification messages during the restoration to notify the client about the status of the process. Added also a root_path string field to the request message.
• CLI: added wallet restore command and related flags.
• Domain: fix storing given accounts within NewWallet factory function
• Pg Repo: fix utxo nullable fields & fix persisting existing wallet accounts when creating wallet into the db
• Bc scanner: added 2 new APIs RestoreAccount and GetUtxosForAddresses used in wallet restore process. Added their implementation and related required changes to the electrum-based scanner.

How it works

To restore a wallet, the app service initially interacts with the bc scanner to restore all the wallet accounts and related used internal and external addresses. Once all the accounts are restored the wallet is initialized and persisted in the repository. After that, the app service interacts with the scanner again to restore the utxo pool of the wallet, which include spent and unspent tx outputs. The restoration is now complete, the only thing missing so far was to store not only the utxos but also the txs related to all accounts. This is done asynchronously after unlocking the wallet. This operation doesn't affect the behavior of the wallet at all.

Please @tiero @sekulicd review this.

[altafan]

@tiero @sekulicd I want to point out that at the moment for the restoration process we use hardcoded values for the account threshold (3 - the number of consecutive accounts to be found empty in order to consider the restoration completed) and addresses threshold (100 - the number of consecutive addresses to be found unused to consider the restoration of a wallet account completed).

Do you think these values should be configurable? If yes, maybe would be better to let the user specify them within the proto request message rather than having some dedicated env vars?

[tiero]

Yes gapLimit should be configurable via request.

Also, shouldt Restore RPC be fired for each "account" (I mean namespace here)?

Ie.

• CreateWallet(mnemonic, password)
• RestoreAccount(namespace,rootPath,scriptTypes)

[altafan]

I'm afraid this adds too much interactivity to the process though.

At the moment, instead, the accounts are discovered and the discovery stops when 3 consecutive accounts are found empty, and, also, there's only one dedicated rpc RestoreWallet for the process.

I think it could be enough to make this threshold configurable in the request message, just like the address one.

[altafan]

Yes gapLimit should be configurable via request.

Done. If the fields are not defined, ocean defaults to the hardcoded previously mentioned.