[bisq-network/bisq] Allow spending of unconfirmed BSQ change outputs (#2482)

Manfred Karrer notifications at github.com
Fri Mar 1 22:46:27 UTC 2019


ManfredKarrer commented on this pull request.



> +        Transaction parentTransaction = output.getParentTransaction();
+        if (parentTransaction == null)
+            return false;
+
+        // If it is a normal confirmed BSQ output we use the default lookup at the daoState
+        if (daoStateService.isTxOutputSpendable(new TxOutputKey(parentTransaction.getHashAsString(), output.getIndex())))
+            return true;
+
+        // It might be that it is an unconfirmed change output which we allow to be used for spending without requiring a confirmation.
+        // We check if we have the output in the dao state, if so we have a confirmed but unspendable output (e.g. confiscated).
+        if (daoStateService.getTxOutput(new TxOutputKey(parentTransaction.getHashAsString(), output.getIndex())).isPresent())
+            return false;
+
+        // 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);

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/2482#discussion_r261782540
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190301/ddbe5d70/attachment.html>


More information about the bisq-github mailing list