Re: Can commit conflicting txs

[Oscar Guindzberg]

The original objective of the IN_CONFLICT state feature was to be able to
warn users a pending tx (payment) they received was double spent.

In your case, you are trying to prevent accidental double spends created by
yourself - because you are not calling commitTx() just after completeTx().

I am fine with adding a failOnconflict parameter to maybeCommitTx (as long
as the method is overloaded with failOnconflict default to false). I would
also agree with the alternative suggested by Andreas, but I would name the
method "boolean isDoubleSpend()"

Maybe I am missing some use case info here, but I am not sure this fix
completely solves your use case. If 2 channels are being opened at the same
time, you may end up with an unintentional double spend anyway because the
other party may broadcast the funding tx.
On a client wallet it wouldn't hurt to make sure you are not opening 2
channels at the same time.
On a hub, you may want to do some kind of pessimistic locking i.e. marking
UTXOs as being "about to be spent" (without commiting the tx that spends
them) so no other thread uses them. bitcoinj provides no support for this
so you would have to code it yourself. Another way to achieve this would be
an unCommitTx() method.

Oscar



On Fri, Sep 1, 2017 at 5:36 AM, Andreas Schildbach 
wrote:

> 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
> > .
> >
> > > 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.
>
>
> --
> You received this message because you are subscribed to the Google 

Re: Can commit conflicting txs

[Andreas Schildbach]

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
> .
> 
> > 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.


-- 
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.

Re: Can commit conflicting txs

[Pierre]

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.