We used checkpoint files from BitcoinJ 0.14.4 and those caused a very
slow initial download. I tested with the WalletAppKit and different
release version sof BitcoinJ and could reproduce the behaviour there.
WIth v0.14.5 it was much better. But also that caused slow startup in
Bisq. After creating a current checkpoint file and using that the
download is now very fast.
Also added logging for versions of BitcoinJ and libDohJ so that we have
better control which version is used.
This change fixes#2048 by removing the assignment of a default value
for the `baseCurrencyNetwork` option at the level of the command line
option parser. The assignment of this default was an oversight in #1961
(specifically commit 83e1dd3) that did not account for the fact that
users can change the `baseCurrencyNetwork` value via the Settings screen
in the application. When users change the setting in the application, the new
value is persisted to <appDataDir>/bisq.properties, which is handled at
runtime as a PropertySource with lower precedence than the command line
property source, which means that the changed value is never picked up
because the higher-precedence command line PropertySource always has a
default value.
This fix is surgical in that it addresses only this specific option. A
subsequent change should address the more general issue that setting
defaults in the command line option parser always precludes the
possibility of overriding them in bisq.properties. Basically, we should
revert to the previous strategy of reporting what the default value will
be in the help text without actually assigning a default value in the
option parser using the `defaultsTo` method.
In case of reorgs there are several scenarios:
1. We have no snapshot yet: We start from genesis again
2. We have a snapshot and go back to that: We use last snapshot
3. We have a snapshot but the reorg does deeper so our last block in the
snapshot is invalid as well: -> we go back to genesis
There are many edge cases
There was one important bug fix with a == instead of an equals
comparison.
Added also the check that the first block need to be the genesis block.
Unfortunately the chainHeight is set to the genesis height initially
which is not right (should be 0 as we dont have any block and therefore
no chainHeight). To change that will be a bit risky, but for mainnet we
should consider it. There are several usages where a change might break
stuff, for instance the parameter handling.
On Windows, it is likely that cli-output_windows.txt will have CRLF line
endings since core.autocrlf is normally true which converts LF endings
to CRLF on checkout. This causes BisqHelpFormatterTest to fail since
the actual content it is compared against uses LF endings.
As a result, when loading the cli-output_windows.txt file normalize
line endings to LF.
- apply snapshot in case of a reorg and if the snapshot is still empty.
Set chain height to genesis height.
- Handle case if cycles are empty
- Add checks for getLast for linked lists
Resolving the property from the bisqEnvironment via getProperty returns
the default value instead of the program argument value. Not sure why,
seems to be related to recent changes in the property handling.
Rename getValidAndConfirmedBallots to getAllValidBallots.
We cannot do a phase and cycle check as we are interested in
historical ballots as well.
Use warn level for logs in case data is missing and requested to
give more weight to those exceptional cases.
- Only show active bonds in make proposal screen
- Check if ballot exists for evaluated proposals in result view
- Use available amount instead of genesis issuance at market cap
- Fix but with button handler for removing a proposal
- Cleanups
* Clarify existing instructions for CLI Wallet
* Provide instruction to retrieve information from GUI Wallet
* Ensure responsibilities are non-ambiguous with regard to burden of responsibility.
* Fix formatting with newlines
