- Changed display string from "lockup time" to "unlock time"
otherwise it may be confused with how long it takes to lock
up the bond.
- Included estimated time duration (e.g. days) for the unlock time.
When creating a BSQ transaction (actually at commit time as we can create a tx and then
cancel it in the confirmation popup) we store the change output (only that not the other
possible BSQ output) in a persisted list. The BsqCoinSelector will take that list to
allow spending those coins. We use the txType to find the index of the cahnge output.
We only have one change output in the transactions created in Bisq. Multiple change
outputs would be valid but our goal is only increased usability in the Bisq app and it is
not related to validation rules.
We update out list at each new block confirmation.
With that approach we avoid too much dependencies to the BitcoinJ side.
- Add UnconfirmedBsqChangeOutputListService and persisted UnconfirmedBsqChangeOutputList
for storing unconfirmed outputs
- Add lookup for unconfirmed BSQ change outputs at BsqCoinSelector and allow spending if
found
- Pass TxType for walletsManager.publishAndCommitBsqTx calls
- Add TxType to bsqWalletService.commitTx
- Refactor getPreparedSendTx methods for BSQ and BTC sending to one common method with a
coinselector parameter.
- Add getChangeAddress method to BsqWalletService to make change outputs more explicit
- Add unconfirmedChangeBalance to onUpdateBalances handlers
- Rename availableBalance to availableConfirmedBalance in onUpdateBalances
- Unify onUpdateBalances parameter names
When hovering over the available, reserved, and locked BTC balances
in the main view, show the market price valuation based on your
preferred currency.
Fixes https://github.com/bisq-network/bisq/issues/1770
When the application window is being created, it checks what the
maximum bounds for a window is in order to set the window size.
However, multi-screen environments may encounter an
IllegalArgumentException (Window must not be zero).
Just ignore the exception and continue, which means the window will
use the minimum window size since we are unable to determine if we can
use a larger size.
Fixes https://github.com/bisq-network/bisq/issues/2452
- As teh network is used for filtering asset types BSQ has 3 asset
types, one per network we need to use REGTEST as network. The methods
for checking which BaseCurrencyNetwork are using name() now instead of
network as we have 2 times REGTEST.
- Fix bug with not calling showFeeInfoAndPublishMyProposal for bonded
role proposals.
- Set BTC_DAO_TESTNET as last enum to not break existing regtest port
convention which is derived from enum order
- Remove BaseCurrencyNetwork.isBitcoin as always true
-
Currently, the download update task will download the deb package for
any Linux distribution. Not only is this incorrect, but now that we are
able to provide an rpm package (see #2200), the download update task
needs to be able to differentiate Linux distributions and provide
the appropriate package.
The download update task will now differentiate between Debian and
RedHat based distributions (the two distributions for which we have an
install package) and download the appropriate package.
In addition, the isSupportedOS method was changed to exclusively check
for Debian and RedHat based distributions, as opposed to just Linux in
general. This means that any other distribution will encounter the
following error, which seems appropriate:
> Unable to determine the correct installer. Please download and verify
manually at https://bisq.network/downloads
- Rename model.getBtcSyncProgress() to model.getCombinedSyncProgress()
to reflect correct property
- Use bisqSetup.getBtcSyncProgress() instead of
getCombinedSyncProgress() in showFirstPopupIfResyncSPVRequested as we
need to listen to btc progress only not DAO progress.
- Make all PaymentMethod constructors private
- Use PaymentMethod.getPaymentMethodById in Offer for getting the
PaymentMethod. This change a bit the context as now we always create the
PaymentMethod from the actual code base in contrast to the data which
have been used when creating the offer. As our fields as final and must
not change in software updates it should have no issues but we have to
keep that in mind to not alter the default values.
- Added a runtimeException in case the maxTradeLimit does not match one
of our default values.
- Use PaymentMethod.getDummyPaymentMethod(GUIUtil.SHOW_ALL_FLAG)
instead of new PaymentMethod(GUIUtil.SHOW_ALL_FLAG))
- We had an automate remove accounts for those payment methods for long
time, so we can assume that no traders have any of those accounts still
in their persisted user objects and it is safe to completely remove them.
Only part where we cannot remove it is the PB definitions (actually I
think we could remove those as well, but not 100% sure and it seems to
be more safe to mark those as deprecated and leave the entries).
- Assign paymentMethods in static final field
- Add static fields for default trade limits
- Remove deprecated payment methods
- Remove onAllServicesInitialized and use static initializer instead
- Re-purpose maxTradeLimit for indicating risk factor
- Calculate real trade limit in the getMaxTradeLimitAsCoin method
- Rename getActivePaymentMethods to getPaymentMethods
