One thing I was wondering regarding this rule:
2. The new transaction (package) has a sufficiently high fee-rate to place it into the upper N blocks worth of the mempool.
What happens if a transaction gets broadcast at the marginal feerate, so that only a fraction of the network accepts the new transaction because the upper N blocks get filled with higher-feerate transactions before the transaction has reached the whole network?
Of course, once the first block is filled with higher-feerate transactions, there's no need for the transaction to propagate fully quite yet. But will the current transaction relay mechanism automatically proceed to propagate the transaction once a new block has been mined such that the transaction is again within the upper N blocks?
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.
reply
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