Topic: Estimating transaction confirmation Time (Read 312 times)

We are hiring a developer for this project .

Feel free to write if you are interested

Average transactions processed in 10 minutes( for example for the past 100 blocks). So we get a roughly idea of the rate of incoming vs processing rate.

For example:
If the mempool has 2000 transactions that are weighted at 300+ Sat/B , and the incoming txs rate is 0 at the moment.
Lets say the processing rate is about 2000txs per 10 minutes, your algorithm can then determine that the next in the queue are transactions weighted at 300+ Sat/B.

I had a look at core's estimation algorithm. Here are my thoughts from my personal experience:

1. If you did a transaction less than 50sat/byte, its likely to get confirmed over weekend. Doesn't matter if you did the transaction on Monday or on Friday.
2. Higher rate transaction 100+ sat/byte get confirmed within a few blocks, or during daily dip of demand graph(mostly during US night time) or sudden increase of hashrate/streak of blocks
3. Due to 1., core's estimate also does get skewed, for example a low fee tx on Friday night has confirmation time of few blocks, vs same fee tx on Monday night has conf time of thousands of blocks. However, the decay algorithm that prioritizes recent block, does offset this
4. Amount of time a transaction has spent in mempool doesn't effect its confirmation time except a transaction that hasn't reached many nodes. When a block arrives , current set of TX collected by miner may be invalid (due to conflicts). A miner is incentivized to sort the current mempool TX in decreasing feerate after each block.


If we can correctly model the demand graph, it should be possible to reasonably predict confirmation time. I understand there are sudden changes, but overall there are the repeated patterns (like weekend/daily dips).

Feel free to let me know your thoughts

Thanks, very useful. Will have a look at this



Yes, good idea

This is probably just a way of promoting the Earn product, the real URL is likely still https://bitcoinfees.21.co

Sadly, https://21.co hosts other inaccurate and/or inept Bitcoin network statistics too.



You should also add transaction weight to your list of factors. This is probably part of how https://bitcoinfees.21.co are getting it so wrong.

Possibly an "Advanced User" option could be added, to depict the effect of transaction weight on the outcome.

You can take a look at bitcoin core's implementation of fee estimation:
https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0

This is the code itself:
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.h

Hi,

We are developing a project similar to https://bitcoinfees.earn.com/ . We know that bitcoinfees is giving widely inaccurate results. We need to develop a algorithm that can predict confirmation time with reasonable accuracy (or atleast better than bitcoinfees)

Factors that can taken into consideration:

- Mempool size
- Hashrate
- Rate of incoming transactions


Let me know your thoughts on this. If you have any ideas on the algorithm. I am open to keep this opensource(directly connected to bitcoind).