You're right, the isOptInFullRBF() method is only about the one
transaction. It's currently up to the library user to implement a
recursive check. The trouble is however we likely don't have the
dependencies in our wallet; you need to fetch them specifically.


On 10/18/2016 08:49 PM, Tobias B. wrote:
> One additional thing I just noted about isOptInFullRBF:
> 
> Is it reliable? It looks to me as it's not. In BIP125 inherited
> signalling is mentioned which means that a transaction opts into full
> RBF when any of its ancestors explicitly signals RBF by a sequence
> number < FFFFFFFF-1.
> I skipped through the code and it looks to me as we just check all the
> inputs of a certain transaction for their sequence numbers but do not
> consider unconfirmed parent transactions.
> 
> Am Dienstag, 18. Oktober 2016 19:34:57 UTC+2 schrieb Tobias:
> 
>     I have to admit, at the time I asked this I didn't read the exact
>     RBF specification yet and assumed some extra rbf flag bit would have
>     been introduced.
>     But as it's just using sequence numbers < FFFFFFFF-1 just setting
>     them to such a value of course worked perfectly fine.
>     Thanks for the advice.
> 
>     Am Freitag, 30. September 2016 17:25:14 UTC+2 schrieb Andreas
>     Schildbach:
> 
>         Setting the flag is only the easy part. The hard part is properly
>         supporting double spends (and at the same time still support the
>         old
>         behaviour). But yeah, just try it.
> 
> 
>         On 09/29/2016 11:04 PM, Tobias Brandt wrote:
>         > Ok, thanks for the reply.
>         > I want to allow my users to send a transaction again with a
>         higher fee
>         > when it's not confirmed yet. So it would be nice if this will be
>         > supported by the API at some point.
>         > But I'll take a look at how to do it by using sequence numbers
>         too. But
>         > my understanding right now is that there is/will be a special
>         flag that
>         > has to be set to flag a transaction as rbf.. how could this be
>         possible
>         > by using sequence numbers on inputs?
>         >
>         > Am Dienstag, 27. September 2016 14:43:41 UTC+2 schrieb Andreas
>         Schildbach:
>         >
>         >     You can set sequence numbers on inputs so yes you could
>         create an RBF
>         >     transaction, but there is currently no API for double
>         spending.
>         >
>         >
>         >     On 09/27/2016 09:23 AM, Tobias Brandt wrote:
>         >     > With "supported" I mean that it's possible to send an
>         RBF transaction
>         >     > (and send again with higher fee).
>         >     > Maybe that's also already possible and I missed it.
>         >     >
>         >     >
>         >     > Am Montag, 26. September 2016 10:22:06 UTC+2 schrieb
>         Andreas
>         >     Schildbach:
>         >     >
>         >     >     What do you mean by "supported"? There is
>         >     >     TransactionInput.isOptInFullRBF() and
>         >     Transaction.isOptInFullRBF() for
>         >     >     quite some time. They are considered risky by
>         >     DefaultRiskAnalysis, but
>         >     >     you can customize your own analysis if you want.
>         >     >
>         >     >
>         >     >     On 09/25/2016 12:37 PM, Tobias Immernochmeinesache
>         wrote:
>         >     >
>         >     >     > neither do I really think that RBF was a good idea
>         nor do I
>         >     like
>         >     >     peter
>         >     >     > todd a lot (not that this matters but somehow I
>         had to
>         >     mention it).
>         >     >     > But still I have a usecase for the application I'm
>         developing
>         >     >     right now
>         >     >     > where it would be of some use.
>         >     >     > So is it planned to make RBF transaction possible
>         in bitcoinj?
>         >     >
>         >     >
>         >     > --
>         >     > 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+u...@googlegroups.com
>         >     > <mailto:bitcoinj+u...@googlegroups.com>.
>         >     > For more options, visit
>         https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>
>         >     <https://groups.google.com/d/optout
>         <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+u...@googlegroups.com
>         > <mailto:bitcoinj+u...@googlegroups.com>.
>         > For more options, visit https://groups.google.com/d/optout
>         <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
> <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