Delay broadcasting of taker fee tx #2488
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
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.
|
@ripcurlx This would require good testing. We can discuss if it should go into the upcoming release. As it would fix an important issue with lsot taker fees I think it would be worth to try to get it in. |
- 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.
- Add verifiedBsqBalance and unconfirmedChangeBalance - Remove totalBsqBalance - Make text for different balances more explicit
- 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
onParseBlockCompleteAfterBatchProcessing
Closed
- 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.
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.
ripcurlx
approved these changes
Mar 4, 2019
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 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.
ripcurlx
force-pushed
the
avoid-taker-fee-publishing-for-failed-trades
branch
from
ed6fa7b to
db4c6f5
Compare
|
@ManfredKarrer I rebased your PR and solved the conflict. Besides the two missing merge commits to master, also the OfferPayloud TTL change commit is gone as it was changed by you to 9 minutes already in another PR. |
|
I leave it to you to merge, if you want to have another look at my reworked commit history. |
# Conflicts: # core/src/main/java/bisq/core/offer/OfferPayload.java
# Conflicts: # core/src/main/java/bisq/core/trade/protocol/tasks/taker/CreateTakerFeeTx.java
…ailed-trades' into avoid-taker-fee-publishing-for-failed-trades # Conflicts: # core/src/main/java/bisq/core/trade/protocol/tasks/taker/TakerPublishFeeTx.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.