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
This change eliminates the BisqExecutable.description method and
replaces it with proper use of the `describedAs` and `defaultsTo`
methods in the JOptSimple API. This removes the concern of formatting
option argument descriptions and default values from the BisqExecutable
class, and delegates it to the new BisqHelpFormatter (see previous
commit), which is designed for the purpose.
For example, prior to this commit, the help text for the --banList
option read as follows:
--banList=<value>
Nodes to exclude from network connections. (default: )
Now it reads as follows:
--banList=<host:port[,...]>
Nodes to exclude from network connections.
Likewise, previous to this commit, the --logLevel option read as
follows:
--logLevel=<value>
Log level [OFF, ALL, ERROR, WARN, INFO, DEBUG, TRACE]
(default: INFO)
And now it reads like this:
--logLevel=<OFF|ALL|ERROR|WARN|INFO|DEBUG|TRACE> (default: INFO)
Log level
There are a number of further improvements that can and should be made
to the description text of the various options, the types specified for
their arguments, etc, but these will be handled in subsequent commits.
This commit is strictly about refactoring existing parser configuration
to take advantage of the new BisqHelpFormatter.
Prior to this commit, help output for Bisq executables, e.g. Bisq
Desktop itself used JOptSimple's default HelpFormatter implementation,
which creates a quite cramped and hard-to-read output.
This commit introduces a custom HelpFormatter implementation modeled
after bitcoind's own help output. It maximizes readability while making
full use of an 80-character width.
- Remove activationDate
- Refactor ProcessOfferAvailabilityResponse and handle offers from
old versions in case the available arbitrators has changed.
- Remove MakerVerifyMediatorSelection and TakerSelectArbitrator
The mediator handling should be removed as it is not used and not
intended anymore to be used with the current trade protocol, but we
leave that as it is a bit tricky to ensure backward compatibility.
Also the setting of the arbitrator in trade should be further refactored
but as it is also easy to break backward compatibility here we leave
that for now. As we work on the new trade protocol that domain will
become deprecated anyway in the next months...
This change suppresses help output when option parsing fails, e.g. due
to an unrecognized option being specified. This is in keeping with *nix
utility idioms; for example, notice what happens when running `git
--bogus` or `ls --bogus`: they output an error message, and in some
cases a usage message, but they do not print complete help text.
This approach is especially important in the case of an application like
Bisq, where there are many options and the help text is longer than a
typical screen, making it easy to miss the error message altogether, as
it is printed at the top of the screen.
This change also prints the error message to stderr vs stdout, which is
again in keeping with *nix utility idoms.
Usually Bisq is run from its 'shadow jar', i.e. the executable fat jar
that collapses all dependencies and resources into a single file. In that
scenario, only a single 'logback.xml' is included in the fat jar and all
is well.
However, when Bisq is run with a normal external classpath, e.g. from
within IDEA, when using `gradle :desktop:run` or when running one of the
Gradle-generated shell scripts under desktop/build/scripts, multiple
'logback.xml' files are present on the classpath, which causes Logback
to complain with messages like the following:
Found resource [logback.xml] at [file:.../desktop/build/resources/main/logback.xml]
Resource [logback.xml] occurs multiple times on the classpath.
Resource [logback.xml] occurs at [file:.../desktop/build/resources/main/logback.xml]
Resource [logback.xml] occurs at [jar:file:.../core/build/libs/core.jar!/logback.xml]
Note the last line above. The presence of 'logback.xml' in the bisq-core
jar is the 'duplicate'. This is Logback's way of warning the user that
it doesn't know which file should be considered canonical. The only way
to avoid this error message (and the many other lines that get output
along with it) is to remove the offending duplicate file.
This commit removes logback.xml from core to solve the problem described
above. The file is unnecessary in the context of running bisq-desktop,
bisq-seednode, etc, and the only context in which it would actually be
used is when running BisqHeadlessAppMain in core. With that said, the
configuration in the core logback.xml file is identical to the default
Logback configuration, so removing the file has no effect on the logging
output from BisqHeadlessAppMain, and furthermore, it appears that
BisqHeadlessAppMain is not actually in use anywhere right now (it was
added some months ago in anticipation of integrating the new HTTP API,
but this has yet to occur).
In a future change, we should probably return the core module to being a
pure library, without any main methods, and introduce a different
module, e.g. 'daemon' that contains the equivalent of
BisqHeadlessAppMain and whatever logback.xml configuration is
appropriate for it. Doing things this way will avoid the 'duplicate'
errors shown above, because desktop, seednode, etc will not depend on
core module, but will not depend on the daemon module.
This code is no longer necessary after the recent move to JDK10, and
removing it entirely avoids spending unnecessary cycles and eliminates
the confusing "Cryptography restrictions removal not needed" message in
console output.
1. Every bond is defined by its lockup transaction. To make it easy to
track which bonds are confiscated it's easier to track them by only one
txid instead of using a map with a mix of lockup txoutputs and unlock
txoutputs.
To check if a txoutput has been confiscated it has to be checked against
the originiating lockup txid.
2. Minor fixes of naming lockedup -> lockup and comments.
The last selected payment account gets persisted so that at the next
take offer attempt that same account is selected in the combo box in
case there are multiple accounts for that currency.
We play a silent sound to prevent app nap and network disconnections.
Instead of a temp file which got deleted on exit and recreated each
startup we store it once in the data directory root.
Fixes https://github.com/bisq-network/bisq/issues/1931
From the changes in isCryptoCurrency which return true in case of BTC
there have been some bugs. We changed the check to distinguish between
altcoin and fiat to check for BTC as base currency now.
That area would require a bigger refactoring...
- We return true at isCryptoCurrency in those cases:
- The code is BTC
- The code is found in assetRegistry
- If not found we check if we have a fiat currency for that code,
if not we treat it as crypto (case of a removed asset)
- cross check the isCryptoCurrency method if the symbol matches any
fiat currency and of both not match consider it still a CC. In case of
a removed asset it was returning false before which caused an issue in
the trade currency pair showing both sides as BTC.
- Show N/A for name in case the asset is not available.
The code mostly operates with the ticker symbol which gets stored in
the offer, so even an asset is removed traders who have that asset in
their account list can trade without problems.
Tested create offer, take offer and executing a trade.
It is no longer necessary to publish Maven metadata about common, core
and other submodules as they are no longer managed as separate libraries
in separate repositories. The only way these modules should be getting
referenced is from within applications in this repository such as
desktop, statsnode, etc. Essentially, we're no longer publishing our
libraries for public consumption.
- Add BondedRoleState to reflect all diff. states.
- Show in UI correct state and button state for lockup/revoke
- Rename ProposalService classes to ProposalFactory
That was a big commit with restructuring the packages and classes.
Motivation was to isolate the daoState value objects so it is more clear
which data are help in the daoState. As it was hard to keep an overview
and easy to add mutable data I think that makes it more safe overall.
I am aware that the downside to take out domain models from the domain
packages is not so nice.
Also moved blockchain models to parser and full node packages.
That was a big commit with restructuring the packages and classes.
Motivation was to isolate the daoState value objects so it is more clear
which data are help in the daoState. As it was hard to keep an overview
and easy to add mutable data I think that makes it more safe overall.
I am aware that the downside to take out domain models from the domain
packages is not so nice.
Also moved blockchain models to parser and full node packages.
That was a big commit with restructuring the packages and classes.
Motivation was to isolate the daoState value objects so it is more clear
which data are help in the daoState. As it was hard to keep an overview
and easy to add mutable data I think that makes it more safe overall.
I am aware that the downside to take out domain models from the domain
packages is not so nice.
Also moved blockchain models to parser and full node packages.
This is the first of a series of renaming commits. We want to use role
for the immutable class and BondedRole for the wrapper which contains
role and the mutable state.
- We store the bonded roles in the evaluated proposals in the dao state.
From there we can get the bonded role object as it is part of the
bonded role proposal. Though we need to take that data immutable
(next commit will handle that)
Enums must not be used directly for hashCode or equals as it delivers
the Object.hashCode (internal address)!
The equals and hashCode methods cannot be overwritten in Enums.
It was only applied to classed which are used as value objects and
potentially are used in Sets or other context which involve usage of
equals or hashCode
- on css there are some changes marked with MK. @Christoph - please
check if those are ok for you, otherwise lets discuss...
- in Formbuilder there is removed the automatic setting of the column
span and index
- Add support for columnIndex as parameter
- setMouseTransparent for addTopLabelTextField is removed (we want that
user can copy text)
- Adjustments in the DAO code are WIP and can be ignored by @Christoph
- Change type of param value from long to string for more flexibility
- Add BTC recipient address param
- Add validation, refactor param value formatter and param value parser
As take offer screen is WIP the fee display is also just a raw draft.
For the DAO state we should add a new group for the fee selection as
it is a bit lost in between the other fields...
We assumed a BTC price of 10 000 USD and a BSQ rice of 1 USD to get a
90% discount if the user choose the BSQ fee. As BTC price is more in
the 6000 USD range we adjust the BSQ fee to stick with the 90% discount.
For the upcoming API work we use java fx classes also in common (PR
is pending), so that is one reason to move that. But there was also an
issue on Linux (travis) as the platform property was not set in the
core gradle build file, but it is already defined in common.
- Change FULL_DAO_NODE option from boolean to string to be able to detect not set values
- isFullDaoNode, rpcUser and rpcPw can be set in the UI. If prog ars are
available they will overwrite the UI data.
- We introduce a new basic storage type for reading from a resource file
if available and reading initial db file if available. That is required
for the snapshots of the DaoState which will be shipped with the source
code.
- We separate the support for maps to MapStoreService
