This prevents a scammer to use publicly known account details
(without being in control of the account) as a seller to get
signed by a buyer. The money received in the seller account might
not be detected by the legitimate owner and/or the money not sent back.
30 days later the scammer could use this signed account as seed to peer sign other stolen accounts.
* Updated price node list for monitor
* Price monitor is more resilient against timeouts
Recenty, a price node got removed. Unfortunately, this node
has been the first in the list of configured price nodes in
the monitor configuration.
A misplaced catch block caused the loop to stop instead of
trying the next configured price node in the list.
* Monitor selects a price node randomly
Up until now, the monitor always chose the price nodes
in their configured order. This resulted in querying
always the same node and thus, create a bigger system
load for this very node. Only in case of a failure,
the monitor moved on to another node.
Shuffling the list of nodes prior to querying provides
at least some load balancing for the price nodes.
* Fixed monitor market API query
The format of the market API response changed. Formerly,
there has been one line, now it is pretty print json.
* Add RefundAgent messages to monitor
Add the relatively new RefundAgent message to the monitor.
* Adjust monitor timeout
Observed, that a timeout of one minute works better than
the original 90 seconds.
Remove the type parameter from Popup<T>, as it appears to have never
been used or set anywhere in the code. (This mainly involves replacing a
lot of "new Popup<>" occurrences.)
* Implement installation path check on Windows
Prior to starting the installation, check if the install location
contains special characters and if so use a different default install
location as well as display a prompt to the user providing additional
details.
This is in response to #3605, for which a proper solution has yet to be
found.
* Ensure the destination location dialog is always shown
This resolves#552
* Show the Welcome dialog
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.
* Reorder/group setup items logically
Rather then potentially being greeted with the newly implemented
prompt on the destination location dialog if they have special
characters in their install path, greet the user with the Welcome
dialog when they initially launch the installer.
Prior to starting the installation, check if the install location
contains special characters and if so use a different default install
location as well as display a prompt to the user providing additional
details.
This is in response to #3605, for which a proper solution has yet to be
found.
After the upgrade from Gradle 4.10.2 to 5.6.4 in commit 5fe71fa0a,
all of Bisq's shadowJar tasks started failing Gradle's incremental build
checks. This meant that repeated invocations of `gradle build` went from
a handful of seconds to more than a minute, because shadowJar tasks had
to be re-executed on every build.
For example, with --info enabled, one would see entries like this in the
build output:
> Task :seednode:shadowJar
Custom actions are attached to task ':seednode:shadowJar'.
Caching disabled for task ':seednode:shadowJar' because:
Caching has not been enabled for the task
Task ':seednode:shadowJar' is not up-to-date because:
Output property 'archiveFile' file [...]libs/seednode.jar has changed.
This problem was solved by in johnrengelman/shadow#524 and made
available in the project's recent 5.0.2 release. This patch simply bumps
the shadow plugin version to that value, and gets us back to snappy
incremental builds, e.g.:
$ gradle build
BUILD SUCCESSFUL in 7s
Up until now, the monitor always chose the price nodes
in their configured order. This resulted in querying
always the same node and thus, create a bigger system
load for this very node. Only in case of a failure,
the monitor moved on to another node.
Shuffling the list of nodes prior to querying provides
at least some load balancing for the price nodes.
Recenty, a price node got removed. Unfortunately, this node
has been the first in the list of configured price nodes in
the monitor configuration.
A misplaced catch block caused the loop to stop instead of
trying the next configured price node in the list.
