- We had it initially at 60 sec. and increased it as attempt to fight
those timeout errors, but it did not help. So letting the user wait
longer as needed does not make sense.
To avoid the issue with lost taker fees if the take-offer attempt fails,
we delay the publishing of the taker fee tx just before the deposit tx
gets published.
The taker fee tx must not be committed to the wallet to avoid that the
wallet would require a resync in case the tx is not published.
If the tx is not committed the addresses used there are not considered
as used and that would cause issues with the address entry context
assignment for the deposit tx. To avoid those issues we need to force
the creation of new addresses used for the multisig and payout address
entries. To be sure that happens before any of the following tasks make
use of those address entries we do that already in the createTakerFee
task.
For BSQ fee tx it behaves similar but needs separate testing.
- We get about 300 refresh msg / min. That causes quite a bit of load
for the network. I think it is safe to increase TTL from 7 to 9 minutes
and change REFRESH_INTERVAL from 5 to 6 min. and
REPUBLISH_INTERVAL from 30 to 40 min.
- Add program args: msgThrottlePerSec, msgThrottlePer10Sec,
sendMsgThrottleTrigger and sendMsgThrottleSleep
- Add ConnectionConfig class with static injected field in Connection
- Cleanups
We got reports that offers got removed and re-added even if the maker
had good network connections. Seems the network did not propagate the
refresh msg in time or get too crowded. Increasing the TTl should help
to make those cases more rare. To decrease the refresh rate from 5 min
to 4 min. might be more risky as it would create much more traffic.
- We had it initially at 60 sec. and increased it as attempt to fight
those timeout errors, but it did not help. So letting the user wait
longer as needed does not make sense.
- To ensure the balance is updated in case we have a comp. request we
need to ensure that the vote result is completed before our balance
update is called.
- Remove updateBsqWalletTransactions call at constructor as nothing is
ready anyway here
- Refactor: Rename addBsqStateListener to addDaoStateListener
and removeBsqStateListener to removeDaoStateListener
- 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.
To avoid the issue with lost taker fees if the take-offer attempt fails,
we delay the publishing of the taker fee tx just before the deposit tx
gets published.
The taker fee tx must not be committed to the wallet to avoid that the
wallet would require a resync in case the tx is not published.
If the tx is not committed the addresses used there are not considered
as used and that would cause issues with the address entry context
assignment for the deposit tx. To avoid those issues we need to force
the creation of new addresses used for the multisig and payout address
entries. To be sure that happens before any of the following tasks make
use of those address entries we do that already in the createTakerFee
task.
For BSQ fee tx it behaves similar but needs separate testing.
- 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
