Correct wording of transaction confirmation popup to use 'mining fee'
instead of 'transaction fee' to make it consistent with wording of
the BTC confirmation popup.
Adds a check that chain height is within 3 blocks of the reported
height from bitcoin peers -> if not the user cannot take an offer
or have an existing offer taken. It shows a message informing the
user that Bisq is not currently synced, advising them to do an
SPV resync if necessary.
Additionally under Settings/Network a field has been added
to show the chain height of Bisq vs the Peer group.
Added after discussion with chimp1984:
- Correct initialization of chainHeight property
- Rename "Latest BTC block height" display field for clarity
- Enforce chain sync rule for Take Offer scenario
- Enforce chain synch rule for Check offer availability scenario
- change method name to be clearer
The display of fee rate on the startup screen is misleading because
at startup a fee has not been received from the mempool fee service
and instead the default value of 50 sats is shown.
This change causes the fee rate not to be displayed until a response
has been received from the service.
Fixes#4765
Recently, some Monero traders were complaining the XMR/BTC price on the
Bisq Price Index was off from most exchanges. Indeed, it seems HitBTC is
trading at a -10% divergence for some reason, I guess they have low
liquidity or some other reason, but after taking a look we are currently
using HitBTC for the following assets:
* AEON - only 2 trades ever, last traded March 2019
* EMC - never traded
* GRIN - looks like only fake trades, last traded Jan 2019
* PART - only 7 trades ever, last traded August 2020
* XRC - last traded December 2019
* XMR - obviously very important for Bisq
So I feel it's worth it to drop HitBTC as a data provider from Bisq to
make the Monero traders happy and make the Monero price more accurate.
The y-axis tick mark labels for crypto (non-fiat)
currencies have a large number of trailing zeroes.
This commit removes the last 3 zeroes from the display.
Util for removing pending mailbox messages in case the
trade has been closed by the seller after confirming receipt
and a AckMessage as mailbox message will be sent by the
buyer once they go online. In that case the seller's trade
is closed already and the TradeProtocol is not executing
the message processing, thus the mailbox message would not
be removed. To ensure that in such cases (as well other
potential cases in failure scenarios) the mailbox message
gets removed from the network we use that util.
We used a delegate method in P2PService for calling readPersisted on p2PDataStorage and peerManager.
This was from old times when those classed have not been injected classes. The complete handlers got
called from both p2PDataStorage and peerManager but we counted only P2PService as host, so the
countdown completed before the last host was really completed, leading to a nullpointer in
MainView (not always).
We removed now PersistedDataHost interface from P2PService and use P2PDataStorage and PeerManager to be added to hosts.
- Use fileName not getFileName() in readHistoricalStoreFromResources
- use complete handler once reading of all historical data is completed where we
build the ImmutableMaps and complete the readFromResources method
This is in accordance with https://github.com/bisq-network/proposals/issues/264
Any account type that doesn't need signing can now trade the full
amount immediately, same goes for signed type accounts that are
selling.
Signed type accounts that are buying now has minimum limit (0.01 BTC) up until
30 days after getting signed, then the limit is increased to 0.5 times the max
limit (0.125 BTC) and after 60 days they get the full limits (0.25 BTC).
