Synchronize node-wallet even when no user-wallet has yet been unlocked

[guidiaz]

This way, if the user sets Sheikah to be launched during OS start-up, the average user would avoid the annoyance of having to resync when unlocking the wallet after a few months.

[Tommytrg]

When Sheikah starts, it connects to the wallet server. AFAIK, the wallet cannot know if there is relevant information in the blocks to keep because everything from the wallet is encrypted. Maybe @aesedepece or @tmpolaczyk can say something different.

On the other hand, I think this issue should be placed in witnet/witnet-rust

[tmpolaczyk]

True, the wallet is encrypted so it cannot start synchronizing without user interaction to unlock the wallet. The closest thing we can do is to have the wallet download all the new blocks ahead of time, and this way when unlocking a wallet the sync will be much faster.

[aesedepece]

True, the wallet is encrypted so it cannot start synchronizing without user interaction to unlock the wallet. The closest thing we can do is to have the wallet download all the new blocks ahead of time, and this way when unlocking a wallet the sync will be much faster.

Such a change would potentially rise up the storage requirements for running a Sheikah wallet to dozens of GBs. The assumption has always been that the wallet component is CPU intensive—so to speak—but has a small storage footprint.

So let's take a step back and clearly state what are the main points here:

• Speeding up synchronization time is always nice.
• It sounds like there are opportunities a wallet can do to keep itself synchronized in the background, or at least to collect transaction data to be applied.
• A wallet server provides public methods (any process in the same host can query them) and private methods (require unlocking a wallet by means of providing a password to use with PBKDF2, etc.)
• Currently, the wallet software can only gain knowledge of wallet addresses once that wallet is unlocked.
• Synchronization while a wallet is not in the foreground is already in place, but an initial unlocking is still needed.

At that point, one could easily think "ok, so let's keep a copy of the addresses outside of the encrypted wallet, accumulate the transactions that affect them into a different collection, and then copy them into the wallet state once unlocked. For as long as no public method gives them away, we should be good privacy-wise and we can get synchronization started without a need to unlocking".

And this is where you expect me to destroy that thinking, right? Surprise: I will not. Because that sounds like a very reasonable option with little to no compromises to privacy.

Just one little problem arises immediately. Not all the addresses for a wallet are known ahead of time, and we can't derive addresses from the BIP32 tree while the wallet is locked. So we may have to increase the BIP32 look-ahead from its current setting (10?). Then, once all pre-computed addresses for a wallet are used, we have to stop collecting info for that wallet and wait for the next unlocking to resume synchronization in the standard way.

This mechanism could be specially interesting for users struggling to keep several wallets in sync, as all of those should be able to synchronize at the same time with a single pass over the block chain, and keep their synchronization chain tips at the same heigh (except in the address shortage case above, and the case in which a wallet is imported or resynchronized manually).