Closed altafan closed 1 year ago
@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?
Yes gapLimit should be configurable via request.
Also, shouldt Restore RPC be fired for each "account" (I mean namespace here)?
Ie.
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.
Yes gapLimit should be configurable via request.
Done. If the fields are not defined, ocean defaults to the hardcoded previously mentioned.
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
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 aroot_path
string field to the request message.wallet restore
command and related flags.NewWallet
factory functionRestoreAccount
andGetUtxosForAddresses
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.