Quote from: o_e_l_e_o on Today at 02:56:44 PM

What you are missing is that you are making the assumption the mempool size remains the same.

We cannot predict what the mempool will do. We cannot predict how many new transactions are going to be broadcast, how large those transactions are going to be, or what fee those transaction will pay. We also cannot predict whether we will find 10 blocks in the next hour or 0 blocks in the next hour. As such, every fee estimation is exactly that - an estimation.

Having said all that, an estimation of 11.7 sats/vbyte for 3 days is on the low side, since we've got over 90 MvB of unconfirmed transactions above this level already in the mempool, even without taking in to account any new transactions. For 3 days right now I would probably go somewhere around 16 sats/vybte which is about 20 MvB from the tip, but it's still just an educated guess.

Not sure how corefeehelper computes those estimates, but I don't think it makes those estimates with the "hope" of the mempool somehow magically clearing in the next days. After all, its estimates dynamically change as the mempool size fluctuates, so I think corefeehelper publishes those estimates periodically under the assumption that the mempool size remains the same at the time of those estimates are published.

Maybe someone from corefeehelper could shed some light.

Also some wallets e.g. electrum provide an estimate themselves based on mempool size and selected fee, so maybe someone pointing to their code on computing this estimate would be also interesting.

Quote from: o_e_l_e_o on Today at 02:56:44 PM

The thing to do is to make sure you enable RBF on all your transactions. That way if it gets stuck, you can easily bump the fee higher.

I know the basics, the discussion is about miner logic on selecting transactions and transaction processing estimates.