Introduces LocalBitcoinNode::willUse and ::willIgnore to move logic that
was previously littered throughout the codebase into one place. Also,
changes the usages of LocalBitcoinNode to be more precise, specifying
which of these questions are being asked:
- "is there a local BTC node" (isDetected);
- "is it well configured" (isWellConfigured and isUsable);
- "will we ignore a local BTC node even if we found a usable one"
(willIgnore);
- "is there a usable local BTC node and will we use it" (willUse).
These changes make related logic much easier to maintain and to read.
It's quite amazing how obvious this was, yet I missed it for such a long
time. Simplifies usage of LocalBitcoinNode and its internals even more
so. Fixes#4005. The way we structured LocalBitcoinNode was as if the
detection checks were expensive, but they're not. Previously, in some
cases we would notice that a local BTC node wouldn't be used even if it
was detected, so we would skip these checks. This optimization now
doesn't happen. It might be reimplemented in a coming change where more
local BTC node logic is moved into LocalBitcoinNode, but, even if it's
not, this check is fairly cheap. A notable exception is if the local BTC
node is not responding, which would cause us to wait for a timeout, but
if that is the case the mentioned optimization wouldn't help (most of
the time).
The workings of LocalBitcoinNode significantly changed, especially how
detection works. Before, we were only checking if a port was open, but
now we're actually performing a Bitcoin protocol handshake, which is
difficult to stub. For these reasons the old tests are irrelevant and
replacement tests were not written.
Refactors LocalBitcoinNode and adds detection for local Bitcoin node's
configuration, namely, whether it is pruning and whether it has bloom
filter queries enabled.
The local node's configuration (and its presence) is retrieved by
performing a Bitcoin protocol handshake, which includes the local
Bitcoin node sending us its version message (VersionMessage in
BitcoinJ), which contains the information we're interested in.
Due to some quirky BitcoinJ logic, sometimes the handshake is
interrupted, even though we have received the local node's version
message. That contributes to the handshake handling in LocalBitcoinNode
being a bit complicated.
Refactoring consists of two principle changes: the public interface is
split into methods that trigger checks and methods that retrieve the
cached results. The methods that trigger checks have names starting
with "check", and methods that retrieve the cached results have names
that start with "is".
The other major refactor is the use of Optional<Boolean> instead of
boolean for storing and returning the results, an empty Optional
signifying that the relevant check was not yet performed. Switching to
Optionals has caused other code that queries LocalBitcoinNode to throw
an exception in case the query is made before the checks are. Before,
the results were instantiated to "false" and that would be returned
in case the query was made before the checks completed. This change has
revealed one occasion (Preferences class) where this happens.
* Add signing debug logs
Fix warning about possible nullpointer exceptions. Better to have an
explicit check for debug purposes.
Smaller cleanups
* Fix codacy comment
* Add keyboard shortcut for trade process refresh, fix#3905
Trades have been getting stuck in the `Wait for payment` state, perhaps
due to lost mailbox messages, but it's hard to know for sure. There is
currently no way to get out of this state except going to mediation.
With ctrl+R the seller can ask the buyer to refresh the current trade
state and the buyer will resend the
`CounterCurrencyTransferStartedMessage` if they are in the phase
FIAT_SENT.
* Disallow more than one trade refresh per day
* Add refresh button for seller step 2, fix#3905
A seller can ask to refresh the trade process once every 24 hours. This
step has been a problem causing a lot of mediation lately so this is a
way to ask the buyer to resend the CounterCurrencyTransferStartedMessage
This fixes the problem when a mailbox message was lost. To test the
seller need to not get the first CounterCurrencyTransferStartedMessage
sent by the buyer, for example by letting the seednode drop it instead
of sending to the seller. When button is pressed
- a RefreshTradeStateRequest is sent from seller to buyer
- the buyer receives the RefreshTradeStateRequest and
- ignores it if it's not in FIAT_SENT phase
- responds with a CounterCurrencyTransferStartedMessage if in FIAT_SENT
phase and has already sent a CounterCurrencyTransferStartedMessage
* Fix codacy remarks
Move incoming message handling method to the right section
* Add refresh button info text
Hide refresh section when not available rather than graying out
Added info text:
Sometimes P2P network messages acknowledging payment are not delivered,
causing trades to get stuck. Hit the button below to make your peer
resend the last message.
* Fix codacy issues
Bisq frequently (once per minute) queries our price nodes for up-to-date
price information. It does so by HTTP GET request. However, it provided
a UID via the "User-Agent" HTTP header field. This UID has been a random
number which changed everytime Bisq got started up.
This UID has never been used. Thus, remove it.
* Add new BSQ issued v. burnt chart
Adds a new two-line chart that plots the month-bucketed BSQ issued and
burnt series. Until now there wasn't a direct visual means of
examining BSQ issue and burn together. This chart aims to fix that.
* Change wording from 15 days to 15-day moving average
Co-Authored-By: Steve Jain <mfiver@gmail.com>
* Make chart's title more clear
"BSQ issued v. burnt" > "BSQ issued v. BSQ burnt"
Co-Authored-By: Steve Jain <mfiver@gmail.com>
* Fix spacing between chart and title
* Reduce title-chart spacing from 20 to 10
Co-authored-by: Steve Jain <mfiver@gmail.com>
This prevents unnecessary load on the seednodes from old clients
loading all trade statistic objects on startup as they interpret
the null value as empty string
The code didn't handle before the use case of new trade statistic objects
created by two old clients. This change make it independent of the cut off date
and allows us at a later point to update all trade statistics objects with
depositTxId value of null.
The check for an address entry before finalizing the multisig payout
might prevent a valid payout when the initiation of the trade process
was interrupted. It's better to allow the completion of the trade
and just log a warning.
