You're correct in thinking that the transation won't propagate fully. Situations like that are always going to be possible, as there isn't consensus over mempools.
It would be possible to design a system where transactions are reconsidered for broadcast after fee-rates changed. Though I suspect that isn't necessary, as this should be a fairly uncommon situation, and the original author can also rebroadcast it themselves.
The original author can also do a normal RBF fee bump. To be clear, that gives a situation with (at least) three transactions in total, a, b, and c. Where a->b was a replace-by-fee-rate (RBFR) fee bump, and b->c was a RBF fee bump.
In that situation, from the perspective of nodes that did not receive transaction b, a->c is also a valid RBFR or RBF fee-bump, so they will accept c as well, propagating c to ~100% of all mempools.
I guess in my mind I would want no need for current RBF to exist when there's RBFR :)
reply
Well, one reason is because RBF is probably reasonable at smaller fee-rate ratios. Eg with current rules I can RBF a transaction repeatedly, paying just 1sat/vB more each time. That's more reasonable if I'm paying for the entire bandwidth uses each time, in the sense that the total fee goes up by 1sat/vB each time, even though the fee-rate went up by, say, 1%
With One-Shot RBFR if I could do a replacement with a fee-rate increase of just 1%, during rising fee-rates I could use the "big/small" replacement technique over and over again, using up a lot more total bandwidth each time. Setting the minimum RBFR ratio to something more like 1.25 makes the fee-rate I'm paying grow a lot faster.
But certainly, if one-shot RBFR was the only mechanism implemented, you could still do most of what we need fee bumping for; there's debate over whether the existing RBF rules are reasonable. Maybe you shouldn't be allowed to rebroadcast a transaction hundreds of times, by just increasing the fee-rate a bit each time?
reply