One-Shot Replace-by-Fee-Rate \ stacker news ~bitcoin

pull down to refresh

One-Shot Replace-by-Fee-Rate petertodd.org/2024/one-shot-replace-by-fee-rate

12.9k sats \ 6 comments \ @kr 18 Jan bitcoin freebie

zaps forwarded to @petertodd (100%)

349 sats \ 3 replies \ @shafemtol 18 Jan

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?

235 sats \ 2 replies \ @petertodd fwd 18 Jan

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.

0 sats \ 1 reply \ @shafemtol 18 Jan

I guess in my mind I would want no need for current RBF to exist when there's RBFR :)

10 sats \ 0 replies \ @petertodd fwd 18 Jan

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?

191 sats \ 1 reply \ @shafemtol 18 Jan

Haven't read through the whole thing yet, but:

Here we will propose an incentive compatible solution, One-Shot Replace-By-Fee-Rate, that mitigates prior concerns over replace-by-fee-rate policies by allowing the replacement to only happen when it would immediately bring a transaction close enough to the top of the mempool to be mined in the next block or so.

👏 YES. I've been thinking about exactly this solution since I read the recent discussion about pinning attack issues earlier this year.

Another related realization I had recently is that in many cases there's no need to broadcast a transaction until it has a chance to get into the next block. You can use the time waiting to e.g. batch further payments into the pending transaction or raising the feerate without having to deal with fee-inefficient CPFP or privacy-degrading RBF.

406 sats \ 0 replies \ @petertodd fwd 18 Jan freebie

I've been thinking about exactly this solution since I read the recent discussion about pinning attack issues earlier this year.

If you wrote it down anywhere, let me know and I'll link you to credit your work.

Multiple people have definitely had similar ideas to this, in whole and in part. My contribution is mainly in actually doing the work to write it up nicely as a post. Not coming up with the idea itself.

Another related realization I had recently is that in many cases there's no need to broadcast a transaction until it has a chance to get into the next block.

Quite right!

Notice how if mempools are sufficiently small that all transactions in them get mined quickly, transaction pinning goes away entirely... There's reasons why it's nice to have larger mempools, so people can send lower fee transactions and just wait. The backlog also helps with price discovery. But it's interesting that the larger mempools is precisely why we have the pinning problem to begin with.

One-Shot Replace-By-Fee-Rate furthers this idea of "send it when you're ready for it to be mined" by how the "one-shot" requires you to be ready to pay a sufficiently high fee to get your tx mined in the next block or two.

You can use the time waiting to e.g. batch further payments into the pending transaction or raising the feerate without having to deal with fee-inefficient CPFP or privacy-degrading RBF.

That's a good point too. As much as I'm an advocate of RBF, ideally you don't actually have to use it. Better that you estimate a reasonable fee the first time, and your transaction gets mined first try.

It's impossible to do that 100% of the time if you're trying to save money, because block finding is probabilistic: you can save money by broadcasting a lower fee-rate transaction and hoping that a few blocks get found in a row. Which of course makes it possible for fee-rates to rise while you're waiting. But you can certainly get this estimation right, say, 90% of the time.

There are special cases where the privacy trade-off doesn't really matter. My OpenTimestamps calendars are a good example. Every transaction they make is public anyway, and trivial to deanonymize, so aggressively using RBF to pay the absolute minimum makes sense given that OTS calendars are willing to wait.