Will RBF transactions be supported?

[Tobias Immernochmeinesache]

Hello,

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?

Tobi

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

[Tobias Brandt]

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.

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

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

[Tobias Immernochmeinesache]

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?

[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:
>

> <https://groups.google.com/d/optout>.

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

[Tobias B.]

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.

[Andreas Schildbach]

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.

[Tobias B.]

Ok, I hope this RBF "feature" just gets erased by BU or BC