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.
