Add re-open dispute button to mediation views (not refund agent as
there it might be dangerous if he would close 2 times and pay out twice.
If a dispute was reopened and a message was sent afterwards the receiver
will auto-reopen the dispute as well and the UI shows the number
indicator.
Add search field to traders dispute views.
Fix DisputeMsgEvents which was handling only legacy arbitration cases
and now uses mediation and refund agent. Used to update state in case
the UI is not selected.
Add "send private notification" button for mediators and refund agents.
Add report button for mediators and refund agents
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages for mediators and refund agents.
This is not used for report but might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 5 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT,
TRADE_ALREADY_SETTLED,
PEER_WAS_LATE
Hide NO_REPLY, SCAM and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them).
Add report button:
Generates report text of all disputes with more detailed information
which should be used for reporting.
Add "Dump text of all disputes" button for getting a text representation
of all disputes including the messages. This is not used for report but
might be useful for search, etc.
Do not show legacy arbitration tabs (for traders as well for
arbitrators) if no cases available.
Add 3 new enum entries for Reason for dispute:
OPTION_TRADE
SELLER_NOT_RESPONDING
WRONG_SENDER_ACCOUNT
Hide NO_REPLY and PROTOCOL_VIOLATION in UI (still in code if we still
need it and re-activate them)
Use now the complete object data for signature creation. We use the protobuf data for creating the signature with DER encoding. We restict ourself more regarding backward compatibility but I think it is not a big problem.
If a new field is added to Filter and deployed the maintainer needs to publishes a new filter object. By using the new version he cannot remove the old filter from the network as the protobuf data is different and sig verification on the P2P datastorage level will fail. This is intended to keep the old filter alive for some time to support not updated users. We do not remove invalid filters anymore from our local storage to enable seed nodes to support also old filter objects.
For not updated users the new filter will fail at sig verification because the protobuf data is different. So they ignore the new filter and still use the old filter. For updated users the old filter will fail and the new filter is accepted. As it has a newer date it would also replace the old filter anyway. If the maintainer wants to delete the old filter from the network he can use the old app version and remove the filter. It is recommended to keep a copy of the data directory before the update so that the removal of the older filter is possible.
Refacorings:
- Rename isPeersPaymentAccountDataAreBanned to arePeersPaymentAccountDataBanned
- Rename isSignerPubKeyBanned to isWitnessSignerPubKeyBanned
Improve the warning message to explain why BSQ balances
close to 5.46 are not sufficient to be used for trade fees,
due to dust limits in the Bitcoin protocol.
Fixes#4439
This change moves gRPC boilerplate classes from the :core.grpc pkg
into a new :daemon.grpc pkg.
* The :core.grpc pkg was renamed :core.api, and no longer has any
dependencies on gRPC libraries.
* All core service classes in the :core.api pkg are now package
protected, excepting CoreApi, making CoreApi the only possible
entry point for all Grpc*Service -> -Core*Service calls.
* All grpc service classes in the :daemon.grpc pkg are now package
protected, excepting GrpcServer; the only class depending on
Grpc*Service class is GrpcServer.
* gRPC dependencies were moved from the gradle.build file's :core
subproject to :daemon.
I do not agree that not allowing Throwable in a catch makes the code
better. Unknown exceptions can be easier found if there is an error log
at the code where it occurred.
I would prefer if there is some flexibility like it is the case with the
IDEA code analysis, where one can edit and customize the suggestions.
Ignore annotations would help.
There have been several long delays as well a wrong order of the
shutdown process (wallet got shutdown after network shutdown.
Shutdown is now pretty fast, but depends on open offers and connections.
Previous version had several performance issues:
- We kept tradeStatistics in a lookup map in memory (about 40 MB)
- We built up the StatefulAssets even if it was not used/needed.
Building the StatefulAssets was an expensive call.
- AssetTradeActivityCheck was only used for printing out statistics and
called on startup causing performance cost.
Optimized version:
- We call build the StatefulAssets only on demand (user activates
view). Method call takes now 22 ms.
- We create a optimized lookup map with a tuple of the data we need
and keep it as local variable.
- We removed AssetTradeActivityCheck.
Thanks to the profiling reporting from:
https://github.com/bisq-network/proposals/issues/199
Converted sound file to a 10 second mono noise with lower volume.
Tested with max possible sound volume and it was hardly audible.
Tested a binary built with it and I could not observe the network
degradation issues.
File is not 800 kb instead of 42 MB.
As part of the Tor V3 upgrade, this PR adds 2 new V3 seednodes, and will
start the process to retire older V2 seednodes.
The V2 seednodes will continue operating for 2-3 months during the
retirement phase-out period, after which time we can filter it out from
the network for clients who have not upgraded if necessary.
Pending merge of #4315 and rough consensus to proceed with migration plan in bisq-network/projects#35
wizpriceje6q5tdrxkyiazsgu7irquiqjy2dptezqhrtu7l2qelqktid (@wiz)
emzypricpidesmyqg2hc6dkwitqzaxrqnpkdg3ae2wef5znncu2ambqd (@Emzy)
devinpndvdwll4wiqcyq5e7itezmarg7rzicrvf6brzkwxdm374kmmyd (@devinbileck)
aprcndeiwdrkbf4fq7iozxbd27dl72oeo76n7zmjwdi4z34agdrnheyd (@mrosseel)
ro7nv73awqs3ga2qtqeqawrjpbxwarsazznszvr6whv7tes5ehffopid (@alexej996)
Rename timestamp field which implied it represents an epoch value in
seconds, but the way it was used to build a Date object showed that it
actually expected a millis value.
The lastRequest timestamp is changed to show the last request to a
pricenode.
The previous approach of using the "last provider request timestamp"
does not make sense in the new setup. Each currency rate is based on
rates from several providers, each with their own "request timestamps".
In addition, the pricenode returns the timestamp each rate was
calculated. On top of that comes the timestamp when the Bisq node
queries the pricenode.
Since what is most relevant for the Bisq node is the "freshness" of a
specific rate, the timestamp most indicative of that is the moment when
the pricenode is queried.
