Now that we have introduced remove-before-add, we need a way
to validate that the SequenceNumberMap was written, but nothing
else. Add this feature to the validation path.
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.
It is possible to receive a RemoveData or RemoveMailboxData message
before the relevant AddData, but the current code does not handle
it.
This results in internal state updates and signal handler's being called
when an Add is received with a lower sequence number than a previously
seen Remove.
Minor test validation changes to allow tests to specify that only the
SequenceNumberMap should be written during an operation.
Addresses the second half of #3629 by using the HashMap, not the
protectedDataStore to generate the known keys in the requestData path.
This won't have any bandwidth reduction until all seednodes have the
update and only have the 32-byte key in their HashMap.
fixes#3629
Addresses the first half of #3629 by ensuring that the reconstructed
HashMap always has the 32-byte key for each payload.
It turns out, the TempProposalStore persists the ProtectedStorageEntrys
on-disk as a List and doesn't persist the key at all. Then, on
reconstruction, it creates the 20-byte key for its internal map.
The fix is to update the TempProposalStore to use the 32-byte key instead.
This means that all writes, reads, and reconstrution of the TempProposalStore
uses the 32-byte key which matches perfectly with the in-memory map
of the P2PDataStorage that expects 32-byte keys.
Important to note that until all seednodes receive this update, nodes
will continue to have both the 20-byte and 32-byte keys in their HashMap.
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
Now that the only user of this interface has been removed, go ahead
and delete it. This is a partial revert of
f5d75c4f60 that includes the code that was
added into ProposalService that subscribed to the P2PDataStore.
#3143 identified an issue that tempProposals listeners were being
signaled once for each item that was removed during the P2PDataStore
operation that expired old TempProposal objects. Some of the listeners
are very expensive (ProposalListPresentation::updateLists()) which results
in large UI performance issues.
Now that the infrastructure is in place to receive updates from the
P2PDataStore in a batch, the ProposalService can apply all of the removes
received from the P2PDataStore at once. This results in only 1 onChanged()
callback for each listener.
The end result is that updateLists() is only called once and the performance
problems are reduced.
This removes the need for #3148 and those interfaces will be removed in
the next patch.
This will cause HashMapChangedListeners to receive just one onRemoved()
call for the expire work instead of multiple onRemoved() calls for each
item.
This required a bit of updating for the remove validation in tests so
that it correctly compares onRemoved with multiple items.
Minor performance overhead for constructing MapEntry and Collections
of one element, but keeps the code cleaner and all removes can still
use the same logic to remove from map, delete from data store, signal
listeners, etc.
The MapEntry type is used instead of Pair since it will require less
operations when this is eventually used in the removeExpiredEntries path.
Previously, this interface was called each time an item was changed. This
required listeners to understand performance implications of multiple
adds or removes in a short time span.
Instead, give each listener the ability to process a list of added or
removed entrys which can help them avoid performance issues.
This patch is just a refactor. Each listener is called once for each
ProtectedStorageEntry. Future patches will change this.
