I assume you want an atomic way to check for conflict and commit the
transaction in one go? Otherwise a "boolean canCommitTx()" would archive
a similar goal.

But yes, a maybeCommitTx() sounds right. Oscar, what do you think?


On 08/30/2017 11:44 AM, Pierre wrote:
> After some debugging, I can now see that the maybeCommit function
> doesn't work as I thought it would.
> 
> The behaviour I was observing seems to be done on purpose: it is
> possible to commit two conflicted transactions. Since it is kind of
> counter-intuitive, maybe adding a note to the javadoc  would help?
> 
> Andreas, would you be willing to consider a PR adding a failOnConflict
> boolean to the maybeCommit function? Something like that:
> 
> /**
> * Calls {@link Wallet#commitTx} if tx is not already in the pending pool
> *
> * @param tx The transaction which is being committed to the wallet
> * @param failOnConflict If true, an attempt at committing a transaction
> that double spends an existing pending
> * tx will fail. Otherwise the tx will be added to the wallet and to the
> pending pool,
> * and conflicting txes will have their status updated to {@link
> ConfidenceType#IN_CONFLICT}
> * @return true if the tx was added to the wallet, or false otherwise if
> it was already in the pending pool
> * @throws VerificationException
> */
> public boolean maybeCommitTx(Transaction tx, Boolean failOnConflict) throws 
> VerificationException {
> 
> 
> Or can you recommend some other way of achieving the same goal?
> 
> Cheers,
> 
> Pierre
> 
> Le mardi 29 août 2017 23:11:39 UTC+2, Pierre a écrit :
> 
> 
>     This is a follow up to
>     https://github.com/bitcoinj/bitcoinj/issues/1442
>     <https://github.com/bitcoinj/bitcoinj/issues/1442>.
> 
>     > A while ago we added a new confidence type, IN_CONFLICT. That
>     means two (or more?) pending transactions are in conflict and not
>     all of them will be confirmed (but all of them /could/). I assume
>     this is what you're seeing. To be sure, have a look at the
>     transaciton confidence of tx1 and tx2 after your program run. And
>     also maybe test this on master and on release-0.14?
> 
>     Yes the confidence of both transactions is indeed IN_CONFLICT, but
>     this is actually what I wanted to avoid. My question was really: why
>     doesn't the second wallet.maybeCommitTx(tx2) return false? Isn't
>     that the whole purpose of this function?
> 
>     Context: we use this in the Eclair implementation of the Lightning
>     network. When creating a channel, one party needs to first build a
>     "funding tx", then exchange some information with the other party
>     (mainly: build a cross signed tx that spends the not-yet-published
>     funding tx), which takes time and opens a window for concurrency
>     issues when several channels are created at the same time. What I
>     was hoping is that I would know, before publishing the second tx,
>     that its input was already spent, so I could cleanly handle this
>     instead of just waiting for one of the txes to eliminate the other one.
> 
>     Thanks,
> 
>     Pierre
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+unsubscr...@googlegroups.com
> <mailto:bitcoinj+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bitcoinj+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to