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.
>
> > 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.
For more options, visit https://groups.google.com/d/optout.
