- Add communication messages to Trade protobuf message to be able to
save chat messages per trade
- Add Type enum and field to DisputeCommunicationMessage protobuf to
be able to dispatch Dispute and Trade chat messages properly
- Rename some function as isClient instead of isTrader to make it easier
to understand who is who when two traders are communicating with each
other
Move session classes to core. Break out DisputeCommunicationMessage
handling from DisputeManager and put in ChatMananger prepare for other
uses of ChatManager.
Renaming of DisputeCommunicationMessage would be nice but it's
representing the protobuf messages so the name has to stay.
The naming of DisputeCommunicationMessage has to stay but they otherwise
fit what would be more aptly named ChatCommunicationMessage or something
in that spririt.
On the way to adding chat for traders this is a first step. Mainly just
moving functionality out of TraderDisputeView to Chat class. There are
still remaining dispute functionality that needs to be factored away.
When the duration is a multiple of 10 days (e.g. 110 days) and not
showing zero values, it was incorrectly formatting it as "11" rather
than "110 days".
Changes the status text when BTC sync in progress from:
Synchronized with Bitcoin Mainnet (using Tor): 10.00%
to:
Synchronizing with Bitcoin Mainnet (using Tor): 10.00%
After restoring from seed, the text shown under DAO /
BSQ Wallet / Transactions displays an incorrect progress - the numbers
are swapped. For example:
"Awaiting blocks... Verified 575,868 blocks out of 554,857"
Normally we get the latest block height from BitcoinJ as the
target height, and we request BSQ blocks from seed nodes up to latest
block.
But when restoring from seed, we receive the latest block height
from the seed nodes while BitcoinJ has not received all blocks yet and
is still syncing.
Fixes https://github.com/bisq-network/bisq/issues/2825
Instead of the 3 minutes delay we set the flag from the lite node once
the blocks are received. We delay 20 seconds to allow multiple getBlocksRequests
to finish.
As soon we are over our connection target we start disconnecting seed
nodes though that can be too early as getBlocks requests are still
pending. We delay the disconnect seed handling to 3 minutes after our
first connection so give it enough time to receive the getBlocksResponse.
We have one very suspicious case where the trader created his
account on 15. of March. To be more safe to exclude potential scammers
we decrease the check to 1st of march.
