Bitcoin Forum

I just wanted to share the results of a little experiment I ran earlier today.

I was curious how accurate the fee calculator is in core. I was skeptical of it's accuracy but mostly I thought it would take longer than the projected times. I'll say now that it was much faster than the projected times.

tl;dr 4 transactions all were included in the very next block after being transmitted, despite having vastly different transaction fees, and despite core estimating much longer confirmation times.


Transaction 1:
Based on the transaction fee calculator in core, this transaction should confirm within 25 blocks. (I'm unsure whether that means it will have it's first confirmation within 25 blocks, or that it'll have a recommended number of confirmations within that time.)
This transaction was included in the very next block after I sent it, block 410942, mined by BW.
TX Fee/kb: .00005249 btc
Total Tx Fee: .00010478 btc or 4 cents us.


Transaction 2:
Expected in 16 Blocks, first confirmation in very next block
Transmitted 5:27 AM UTC
Tx Fee / kb: .00009340 btc
Total TX Fee: .00021397 btc or 9.6 cents us


Transaction 3:
Expected in 6 Blocks, first confirmation in very next block
TX Fee / KB = .00016628
Total TX Fee = .0001518182 btc (or 71 cents us for 8.631 kb of data)


Transaction 4
Expected in 2 blocks, first confirmation in very next block
TX Fee/kb = .00030032
Total TX Fee = .00267284 btc (or 1.20 us)

Very interesting experiment, The results are mixed but this should be investigated further.

So it means that whatever transaction fee you will put, it will always get accepted ? I always put little tx fees, and after this results I won't change it. Thank you for this study ;) !

I think that you're off to a good start, but there needs to be a bigger sample size and I think it might be worth factoring in the previous block full-ness and see if different used space in each block has an effect on the transaction fee for the transaction. Also maybe check hashing power and see if increase or decreased hashing rates are also a variable when it comes to transaction fees. No guarantees those factors actually have any affect on the value, but it might be interesting to look into.

I've seen mixed results in the past with tx fees and confirm times. I've had some transactions take a really long time, even with what I thought was a good fee. I never made the time to record or study the results though until now.

I'll definitely be doing this more in the future. I figured it'd be a good historical reference as well. Glad to contribute to the forum and to bitcoin :)

should also include "no fee" test.

Good suggestion. Next time I do this I'll include a no fee test as well.

It is really interesting experiment. It confuses me since i always believed that there was a simple connection between transaction speed and the fee that is paid. Please keep us posted about no fee transfer as well. Thanks.

Absolutely a bigger sample size would be good, and sample sizes spread out over a long period of time.

Hash power changes shouldn't be big enough to change block generation by much. That stuff is graphed pretty well on blockchain.info and other places, but generally the randomness of block generation regardless of the hashpower or difficulty level accounts for bigger fluctuations than hash power fluctuations. That is until right after a halving I suspect.

I'm getting the feeling that it's the politics of the mining pools that affects confirmation times more than anything. I'll update when I run my next test for sure. It will be an interesting metric to keep a pulse on over time.

Thats true, the good thing is you dont need to send the same amount of transaction for every case. To keep the same significance, you dont need as much high fee transactions as the low fee transactions because the expected variability in confirmation times for low fee transactions is expected to be much higher.

Good point, you just saved me some btc I suspect :)

How old were your inputs? That would have affected the priority. High priority stuff gets confirmed pretty fast.

Inputs were all within the last year...

wow Im surprised I didnt think to do this or someone earlier lol

amazing how the most simple ideas sometimes get missed.


good study

And were you sending a fraction of a large input, or a combination of lots of small inputs. Both transaction 3 and transaction 4 look like you were sending a combination of lots of small inputs, combined with a large fee. It got confirmed quickly because of the large fee.

What you really need to do is standardize the fee - make them all 0.0001, and vary the amounts (outputs made up of one big input or lots of small inputs). That way you will be able to see whether the miners make you wait or not.

Also, the protocol says you can send an aged input for zero fee if the kilobytes are low. According to the wiki, "a transaction was safe to send without fees if these conditions were met:

    It is smaller than 1,000 bytes.
    All outputs are 0.01 BTC or larger.
    Its priority is large enough"

Test it out and see if it works. Bitcoiners have spent the last seven years telling everyone that you can send "free" or for a minimal fee - so that is what most bitcoiners do. The question is, is that still true.

You also have to factor in how full the mempool is. Although the Core estimator looks into the mempool**, it may not be accurate. There may be close to no pending transactions in the mempool, therefore putting a low fee tx in the next block.

** Not sure if it does or not

I sent a combination of a lot of small inputs in each case. Correct 3 and 4 were larger than the others, with more data of similar size inputs. The others were less inputs, with fees that were comparably smaller than the difference in size/number of inputs.

Great suggestion, there are a few ways I could change it up to get more accurate data. Next time I do this (if I can ever find the time to do it right) I'll incorporate that and some other ideas to make the test more scientific and thorough.

Those are great things to keep in mind and I'll refer back to this next time I run a test to remind me the kind of things I should keep in mind.

thanks RD  You're the one etc..... :-D

I did some no-fee transaction awhile back and one went through fairly quickly (within 4 hours) and the other took a while longer, maybe 2 days.

Update: Just for fun, I tried again sending a small amount to Polo using a 0 fee transaction. I will report back on how long it takes. Transmitted out just before block 411108.

Transaction ID: 6d10574175e76c7801d7dd0b41f7bfe6c81ff10796ae6968356e52c671375460  if you want to follow along, 0.03834 BTC consisting of several (recent) small inputs from signature payments.

I'm pretty sure you'll get a completely different result if you would run the same test several times spread over a couple of weeks.
As said before, i think it depends on how many transactions are in the mempool, how big they are, which fees they have, which pool mined the blocks, how big the blocks were,.... From time to time, you also see allmost full blocks for 3-4 consecutive blocks. I'm pretty sure that your very low fee transactions wouldn't have been included in this case.