Wallet recovery

[sekulicd]

This adds recovery method that is supposed to return utxos for x number of accounts.

@tiero @altafan please review.

[sekulicd]

Ok, i think i have better idea, to search directly in filters repo. Check SearchTransactionsForOutputScripts method.

@tiero @altafan

[sekulicd]

@tiero @altafan please check restore method which is fetching txs in sync mode based on filter/header repo.

[altafan]

@sekulicd i'm testing the restoration of this mnemonic:

tell worth behave moon duty file alien bacon design element attract era enter turtle cycle foot bone sand elevator useless release affair giggle engage

with this wallet configuration:

OCEAN_NETWORK=testnet
OCEAN_LOG_LEVEL=5
OCEAN_NO_TLS=true
OCEAN_STATS_INTERVAL=120
OCEAN_ESPLORA_URL=https://blockstream.info/liquidtestnet/api
OCEAN_NODE_RPC_ADDR=http://admin1:123@liquid-testnet.sevenlabs.dev:18884
OCEAN_UTXO_EXPIRY_DURATION_IN_SECONDS=240

Since the ocean service doesn't print any log within the process, it's hard to say what's going on but after 5+ mins it's still ongoing. Can you try replicate this?

Also, since restoration can be a long process, we should define RestoreWallet as server-side rpc (this way we can send messages to the client to notify about the status of the process) instead of unary to make sure the connection doesn't timeout client-side (we'll do the same in another PR for InitWallet).

[sekulicd]

Since the ocean service doesn't print any log within the process, it's hard to say what's going on but after 5+ mins it's still ongoing. Can you try replicate this?

I added some logs. Issue is that we are scanning from block_height=0, the tip is 606522 (in the moment of writing) and for each block we have 3 rpc calls(network latency): L211 -> elements/service.go -> s.headersRepo.GetBlockHashByHeight L295 -> elements/service.go -> s.filtersRepo.GetFilter L247 -> elements/service.go -> s.headersRepo.ChainTip So this is going really slow. I think we need to use Neutrino to sync full chain and only then ti start Ocean otherwise recovery will be to slow. Also we are currently passing only 150 scripts to FindTransactionsForOutputScripts method, we should definitely increase this number to few thousands.

[sekulicd]

Since the ocean service doesn't print any log within the process, it's hard to say what's going on but after 5+ mins it's still ongoing. Can you try replicate this?

I added some logs. Issue is that we are scanning from block_height=0, the tip is 606522 (in the moment of writing) and for each block we have 3 rpc calls(network latency): L211 -> elements/service.go -> s.headersRepo.GetBlockHashByHeight L295 -> elements/service.go -> s.filtersRepo.GetFilter L247 -> elements/service.go -> s.headersRepo.ChainTip So this is going really slow. I think we need to use Neutrino to sync full chain and only then ti start Ocean otherwise recovery will be to slow. Also we are currently passing only 150 scripts to FindTransactionsForOutputScripts method, we should definitely increase this number to few thousands.

@tiero @altafan how do we proceed with this?

[tiero]

Let's supersede this in favor of using Electrum JSONRPC over TCP. Bonus is TCP batching compared to the REST HTTP Esplora interface

https://github.com/vulpemventures/ocean/issues/25

[altafan]

Closing in favor of #43.