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.