When doing a resync from genesis the number of blocks is limited to 6000
so that requires lots of requests and with that increases risk of broken
connections. Giving more tolerance for retries avoids that the user has
to restart the app.
When syncing from genesis the number of blocks are limited so we get the
`onParseBlockCompleteAfterBatchProcessing` called each time when the received
blocks are processed, and as we are not at wallet height we repeat requesting
blocks. But the new check for the BTC recipient triggers a resync from resource call.
We add now a check that we do this check only once the wallet is synced and our
block height from dao state matches wallet blockheight.
We had historically higher trade limits and assets which are not in the
currency list anymore, so we apply the filter only for data after
Nov 1st 2021.
PaymentMethod use an instance of TradeLimits and expect that it
has been injected, which is the case for desktop but not for
headless apps, so we enforce injection in the app base classes
used for headless apps.
The validation of trade statistics use a method in PaymentMethod
where that dependency is required.
Tha hack how the PaymentMethod use TradeLimits is not nice, but
would require more effort for refactoring.
found in the active list. Otherwise the 2 BTC default is used.
We get TradeStatistics3 objects from old retired PaymentMethods
which are not found in the active list.
That check is done if:
- If we are after activation time
- If filter is available
- If value in filter is > 0
The check compares the paid fee and the fee value from filter
and requires that paid fee is > 70% of filter value.
See comments in code for more background.
persistance is below the chain height of btc core.
With the new handling of dao state hashblocks it can be the
we have persisted the latest block up to the chain height.
Before that change we only had the last snapshot which was at least
20 blocks back persisted.
We want to avoid to get caught in a retry loop at parseBlocksOnHeadHeight
so we filter out that case just at the caller.
At parseBlocksOnHeadHeight we inline the requestChainHeadHeightAndParseBlocks
method as it is not used by other callers anymore.
This case that we request a block but our local btc core chain hight is below
that might be some edge case when we had a synced dao blocks but we btc core is
resyncing...
