Florian reported that they consume quite a bit of performance.As
they have not been used for development testing since long we should
better remove those.
Use percentage based value of trade amount for buyer and seller
security deposit.
To ensure that the BTC value is not getting too low, we apply a min.
value for both.
- Add LiveAsset account, payment method, AccountPayload
- Extract super classes for normal CryptoCurrenyAccount and payload and
LiveAssetAccount and payload
- Add isAsset method
- Add button for creating a live asset account
As it is a bit tricky to use the AccountForm for both methods and add a
checkbox there so defined which payment method to use I added a button
to add an AccountForm with the LiveAssets passed. This is just
temporary to be able to test a bit more and see if there are any
critical issues. We should unify that form but that might require a bit
of refactoring of the CryptoCurrencyForm.
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
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
- 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).
In case that the users blind vote list does not match the hash of the
majority we want to find if any variation of our list leads to a match
so we can still calculate the vote result.
If a updated client makes a param change request old client do not
recognize that enum. To avoid exceptions ro null pointers we fall back
to the UNDEFINED enum entry if available. As param value we show an empty
string.
Beside that issue no problems have been found so far with adding a new
param entry.
This code is no longer necessary after the recent move to JDK10, and
removing it entirely avoids spending unnecessary cycles and eliminates
the confusing "Cryptography restrictions removal not needed" message in
console output.
1. Every bond is defined by its lockup transaction. To make it easy to
track which bonds are confiscated it's easier to track them by only one
txid instead of using a map with a mix of lockup txoutputs and unlock
txoutputs.
To check if a txoutput has been confiscated it has to be checked against
the originiating lockup txid.
2. Minor fixes of naming lockedup -> lockup and comments.
The last selected payment account gets persisted so that at the next
take offer attempt that same account is selected in the combo box in
case there are multiple accounts for that currency.
