pull down to refresh

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