Allow spending of unconfirmed BSQ change outputs #2482
Conversation
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
There was a problem hiding this comment.
I think this is a better way to handle it than through the parser. I tried using the parser and that's just too risky and hard to control in the end, this way is much more controlled and only very specifically designated change outputs can be spent without confirmation and parsing which is safer.
The problem would be that this is more fragile if we start changing anything in the BSQ parsing as this is now a separate kind of parsing that needs to be handled with great care.
|
|
||
| // Only if its not existing yet in the dao state (unconfirmed) we use our unconfirmedBsqChangeOutputList to | ||
| // check if it is an own change output. | ||
| return unconfirmedBsqChangeOutputListService.hasTransactionOutput(output); |
There was a problem hiding this comment.
Don't we need to check that it's also unspent or is the unconfirmed list only for unspent txs?
There was a problem hiding this comment.
As we remove entries for all connected outputs of any inputs we should not get that problem (e.g. user spend utxo from previously unconfirmed tx). If we would miss one it would throw an error on the BitcoinJ level if we try to use an input which is already spent. But I will have a look to add an additional check.
| */ | ||
| public void onCommitTx(Transaction tx, TxType txType, Wallet wallet) { | ||
| // We remove all potential connected outputs from our inputs as they would have been spent. | ||
| removeConnectedOutputsOfInputsOfTx(tx); |
There was a problem hiding this comment.
Ok, I see the outputs are removed when spent, previous comment is then void since all transactions in the unconfirmed list are unspent.
There was a problem hiding this comment.
Yes, if data hanlding stays in sync it should be ok. Still as we manage parallel data now there might be theoretically an issue (e.g. if persistence fails after remove). I will try to test that scenario to verify that we get an exception from BitcoinJ.
core/src/main/java/bisq/core/dao/state/unconfirmed/UnconfirmedBsqChangeOutputListService.java
Outdated
Show resolved
Hide resolved
core/src/main/java/bisq/core/dao/state/unconfirmed/UnconfirmedBsqChangeOutputListService.java
Show resolved
Hide resolved
- 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
|
@sqrrm I fixed and improved balance display as well as hanlding of confiscated bonds. Can you review the open commits? |
There was a problem hiding this comment.
NACK - Besides the validation problems mentioned below for going over your available balance it looks fine.
@ManfredKarrer Is this error message correct? I don't think that is my available balance to send.
When I try to send an amount that I shouldn't be able to send I get this wrong mining fee warning popup.
|
@ripcurlx Thanks for the finding. Fixed with latest commit. Could you ACK now? |
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.
for storing unconfirmed outputs
found
coinselector parameter.