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

pull down to refresh

406 sats \ 0 replies \ @petertodd 18 Jan freebie \ parent \ on: One-Shot Replace-by-Fee-Rate bitcoin

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.