[FR]: Enhance Pirate sync

[smk762]

Currently there are a few quirks with ARR activation (depending on API version and params used). After some discussion with @cipig and @borngraced and feedback from PIRATE team, a few cases and options have been mentioned as below.

• On first load, sync from the wallet creation date. I'm not sure this is currently stored (though it can be in future). For where we do not have this data, we could use something like a date 2 weeks prior to first swap date.

• In some cases (explained in further detail below), existing cache may not be reused when activating. Adding a boolean use_cache param could better govern this, though there are exceptions (e.g. earlier sync date param than earliest cache data) where it may not be reused. E.g.

  if use_cache == true and sync_params["height"] >= min_cache_height:  # or derived height from sync_params["date"]
  continue_sync_from(max_cache_height)
  else:
  continue_sync_from(rpc_param_height)

• In current API dev branch:

  if not sync_params and cache_exists and use_cache == true:
  continue_sync_from(max_cache_height)
  else:
  continue_sync_from(2_days_ago)

use_cache should default to true

On GUI side, setting the date to sync from in settings is suboptimal:

• its a global setting, so cant define independently for ZOMBIE and ARRR (or future zcoins)
• In current dev branch API, using date param always abandons the cache, leading to long activation times on each use if date set back too far.

This could be solved by:

• Selective use of date setting: use once and discard, so subsequent activations do not use sync_params, and with existing_cache would mean continue_sync_from(max_cache_height). There is potential trouble with this if the one_shot date activation fails or is interrupted, but allows for a simple way to force a rescan (just change the date). Until the use_cache param is available though, it will also force a resync if sync_params["height"] is > min_cache_height
• Alternatively, on every zcoin activation, pop up asks user to define if they want to use a date, height, "earliest" or continue_sync_from(max_cache_height), and use_cache. This is the maximum support for all available params and allows for more specific values for each Z coin.

I think the table below summarises what I would expect from a variety of sync_params value cases

@cipig @borngraced please add any extra info or ideas in this issue so we can find the best path for the next release.

[cipig]

i don't see the need for additional use_cache param the default, when activating without date param set, is to continue from where it stopped, aka use_cache, even if interrupted on previous run (eg by stopping app before sync finished)

the behavior of latest mm2 from dev branch (including https://github.com/KomodoPlatform/komodo-defi-framework/pull/1967) is to overwrite the cache/DB when activating with date param set... it then starts with a clean DB, but at that date... if no sync param set, it continues from where it stopped

the only 2 cases for setting a date sync param is on first start (when no cache/DB there) to make the first sync faster by specifying a date... and when someone wants to forcefully reset DB and resync

if the app would not pass date param at all after a restart of the app, but would do it only in the current session, it would solve the current problem and cover all usecases (i guess this can be achieved by simply not saving the date in cfg.ini, have the variable only set in current session and only pass sync params to ARRR activation when a date is set)

if user activates for the first time it starts at a default (eg 7 days ago, if user hasn't set something else before first activation)... this does not take long... if user is missing balance (eg because utxos older then 7 days in wallet), he would need to disable ARRR, set a date and enable ARRR... the activation would pass the date and mm2 would resync from that date

if user just wants to reset the DB and start again from a specified date, same procedure

in all other cases, it would continue from it where it stopped

EDIT: we could add a button "resync/reset ARRR" in settings... it needs a date as input and it does disable ARRR and enable it back with that date sync param set and on activation after a restart of the app no date param is passed

[smk762]

Issue solved at api level and with block height calc logic generalized to nearest 1000