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