DAO: Submitting a proposal (2 BSQ burnt) labels entire UTXO "unverified" until block is processed, preventing submission of other proposals

[BravoIndia]

See below:

I had 9998 BSQ and burnt 2 to submit the proposal, causing 9996 to be "unverified" until the block was processed.

Since my entire BSQ balance is one UTXO that got spent as an input in a proposal request
(tx: https://explorer.bisq.network/testnet/tx.html?tx=f86258a7ddfbfba163eaa54855ec400342f5e1d51dbedc93205f5e4b34ecff3c),
the remainder (9996) became "unverified" in the DAO gui, preventing other proposal-making until the next block.

Should Bisq be able to recognize the output address is controlled by the same wallet?

Perhaps this is working as intended/there is no workaround, in which case perhaps the warning notice should be updated to make the users aware they simply must wait for the next block? Maybe with a link to the explorer? In general perhaps it makes sense to provide the transaction hash for a proposal made in the confirmation notice.

Thank you

[ManfredKarrer]

Yes that is a known issue. But there is no easy solution. We could try to create additional utxos to one self so you have more available utxos and spening one will not prevent you from further txs until prev. one was confirmed. To support unconfirmed txs is tricky and maybe not possible at all in a secure way. Unlike BT txs we cannot assume by default that we receive only valid BSQ txs. A BSQ tx can be a valid BTC tx (has to anyway) but invalid as BSQ, the BTC nodes are blind to BSQ so they will relay those. A BSQ tx can only be fully validated once it is in the blockchain.

[ManfredKarrer]

This problem will become even more problematic for paying trade fees. Trades doing many offers/trades will not be able to use BSQ for the fee payment if there is only 1 uxto available and the change output unconirmed. A solution for that could be that we split up the change output to multiple utxos so that there are always a min. number (e.g. 5) of utxos available. Not a perfect solution either but would probably solve the problem in 99% of the cases.

[ManfredKarrer]

Improving the popup text would be the first and easiest step. I try to get that done soon.

[BravoIndia]

Good to know, thank you for the explanation. I hadn't considered the trader contingency, indeed that seems problematic. Splitting the UTXO makes sense. Like you said, it isn't perfect, but it's good enough to fix the issue.

It seems like the use-case of BSQ is averse to aggregating your UTXOs in general (as opposed to BTC, perhaps). And except for buying them in the market, they are likely to be grouped in large UTXO if I understand correctly? Because using them as a trading fee or for submitting a proposal burns them?

Maybe a "split UTXO" button on the DAO dashboard is a useful function?
It makes sense for that to not to be done in the background, but to require user confirmation, as it's an action that increases fees; both in splitting, and in a later transaction requires multiple BSQ inputs.

[ManfredKarrer]

I think the extra costs are not such a concern as it only split up in case you have < 5 utxos (the threshold can be set as prog. arg and with that u can set it to 0 as well). Adding too much user options decreased usability specially for such complex and hard to understand areas.

[BravoIndia]

Fair enough, that makes sense.

[ManfredKarrer]

Dropped that idea as implementation caused quite a lot of issues and as trade protocol excepts 1 change output it caused problems there. We could use it for some types of transactios but the most important would have been the trade fee tx and there it does not work with current trade protocol. So we need to postpone that for either supporting unconfirmed transactions (which might be tricky) or until we find a better idea, or to apply to to the few tx types where it works without issues.
Before we go on Mainnet we should have some solution in place.

[ManfredKarrer]

@sqrrm has prepared a PR and is working on that. I will close that issue.