Topic: Bitcoin transaction fees (in sats/kb). Sunday, Saturday are best to move BTC (Read 2566 times)
July 05, 2021, 04:44:25 AM
The situation looks even better this morning. At the moment I am writing this post, there are less than 500 unconfirmed transactions according to what https://mempool.space/ is showing. A 1 sat/vByte is all that is needed today. I hope this lasts.
July 04, 2021, 11:11:26 AM
It's Sunday, around 15 UTC and you have chances to enjoy very low fees.
As of writing, you can get a confirmation in next 1 block if you use a fee rate at 2 to 3 satoshi/ (v)byte for your transaction. Total size of mempool from the tip to 2 sat/ (v)byte is less than 0.77 vMB.
Check the mempool at https://jochen-hoenicke.de/queue/#1,24h
As of writing, you can get a confirmation in next 1 block if you use a fee rate at 2 to 3 satoshi/ (v)byte for your transaction. Total size of mempool from the tip to 2 sat/ (v)byte is less than 0.77 vMB.
Check the mempool at https://jochen-hoenicke.de/queue/#1,24h
June 11, 2021, 11:20:30 PM
-snip-
Though, even with that enabled the total is wrong.
I think I get where your confusion with the total is.Though, even with that enabled the total is wrong.
In "Johoe's Bitcoin Mempool Statistics", the numbers you see in each fee rate range is already the total of the ones on top of each range.
So for example, the value in "1+" is the total size of all transactions from 1~2000+ in the graph.
What's been weird in the site since the update is the seemingly stuck <1sat/vB transactions when you enable to 0+ minimum flag.
But we're getting out of topic, you can start a new thread if you want to continue the discussion about that specific mempool statistic site.
June 11, 2021, 07:05:49 AM
Cool, didn't know about the minimum parameter.
Though, even with that enabled the total is wrong.
Though, even with that enabled the total is wrong.
June 10, 2021, 11:26:52 PM
If that's the case it should show also the 0+ stats line. As it is, the numbers just look wrong.
A few months back, before the redesign, it looked correct.
-snip-
I noticed that too.A few months back, before the redesign, it looked correct.
-snip-
With the updated version, when you try to force the minimum to 0, you'll see that there are a lot of accumulating
<1sat/B transaction in his mempool: jochen-hoenicke.de/queue/#BTC,3m,weight,0
But based from this: /jhoenicke/mempool/blob/master/web/queue/mempool.js
He's using the default mempool setting so there shouldn't be any <1sat/B txn in his mempool, it must be a bug in the site or server.
June 09, 2021, 07:07:09 PM
If that's the case it should show also the 0+ stats line. As it is, the numbers just look wrong.
A few months back, before the redesign, it looked correct.
How do you know, by the way? Did check the source code?
A few months back, before the redesign, it looked correct.
How do you know, by the way? Did check the source code?
June 09, 2021, 11:25:58 AM
When choosing the non-default BTC mempool on Johoe's site, the hover table strangely shows a wrong "total".
Though not a big deal. Just need to mind instead the "1+" line above it.
Non-default mempool doesn't strictly enforce standardness in terms of the minimum mempool fees, the disparity arises with the fact that the graph doesn't show transactions that pays a fee of 0 - 1 satoshi. Since default implementation enforces 1+sat/vbyte, there is no disparity in the total. It doesn't matter because the default puts it at 1 sat/vbyte and is also what most miners enforce as well.Though not a big deal. Just need to mind instead the "1+" line above it.
June 09, 2021, 10:55:01 AM
When choosing the non-default BTC mempool on Johoe's site, the hover table strangely shows a wrong "total".
Though not a big deal. Just need to mind instead the "1+" line above it.
Though not a big deal. Just need to mind instead the "1+" line above it.
February 11, 2021, 01:26:55 PM
Network is so congested right now 80 sat/byte + fees. How long till it gets back to normal???
January 15, 2021, 08:20:12 AM
Today, I give you the update for difference between weekly median of transaction fee and the daily median of intraday transactions.
For the daily median, I run it for days of week: Monday - Sunday.
Then, I calculate the difference (in percent). All results below are for difference (%)
This new analytical method excludes the short- or mid-term effects of bitcoin rises / falls that in turn potentially increase bitcoin transaction fees within a few days, few weeks.
Box plot
- The median values are vertical lines inside boxes (for each Days of week)
- Only 3 days have medians below 0: Monday, Saturday, and Sunday.
- It is a confirmation for weekend effects and the appearance of Monday with negative value somewhat shows the market need Monday to warm up for rest days of week
- With working days: Tuesday to Friday, the highest median is on Thursdays.
Bar chart
- Values in bar chart are means.
- Only 2 weekend days have negative values: Saturday (- 3.01%) and Sunday (- 7.9%).
- Monday is slightly above 0, at 0.13 %.
- The peak is still on Thursday at 6.85%
I did not (but I might) censor data set to recent years as I believe results will be almost the same.
You can combine this update with the hourly analysis above and make weekly, hourly plans for your bitcoin transactions.
Raw results
Code:
Summary for variables: diff_pc
by categories of: dofw
dofw | N mean sd p50 p25 p75 min max
----------+--------------------------------------------------------------------------------
Sunday | 507.0 -7.9 18.7 -5.4 -15.7 -0.3 -100.0 120.9
Monday | 507.0 0.1 15.7 -0.7 -5.4 5.1 -98.1 131.4
Tuesday | 507.0 5.1 21.6 1.6 -3.3 8.5 -100.0 255.9
Wednesday | 508.0 6.5 22.3 2.4 -2.4 10.3 -51.0 231.0
Thursday | 508.0 6.8 19.1 2.8 -1.6 9.7 -100.0 178.5
Friday | 507.0 5.1 18.6 1.8 -2.5 9.3 -100.0 162.3
Saturday | 507.0 -3.0 19.3 -2.1 -10.5 3.2 -100.0 130.3
----------+--------------------------------------------------------------------------------
Total | 3551.0 1.8 20.1 0.2 -5.3 6.4 -100.0 255.9
-------------------------------------------------------------------------------------------
by categories of: dofw
dofw | N mean sd p50 p25 p75 min max
----------+--------------------------------------------------------------------------------
Sunday | 507.0 -7.9 18.7 -5.4 -15.7 -0.3 -100.0 120.9
Monday | 507.0 0.1 15.7 -0.7 -5.4 5.1 -98.1 131.4
Tuesday | 507.0 5.1 21.6 1.6 -3.3 8.5 -100.0 255.9
Wednesday | 508.0 6.5 22.3 2.4 -2.4 10.3 -51.0 231.0
Thursday | 508.0 6.8 19.1 2.8 -1.6 9.7 -100.0 178.5
Friday | 507.0 5.1 18.6 1.8 -2.5 9.3 -100.0 162.3
Saturday | 507.0 -3.0 19.3 -2.1 -10.5 3.2 -100.0 130.3
----------+--------------------------------------------------------------------------------
Total | 3551.0 1.8 20.1 0.2 -5.3 6.4 -100.0 255.9
-------------------------------------------------------------------------------------------
December 26, 2020, 01:09:09 AM
Weekend and also holidays. You have chances to enjoy lower fees.
As of writing, you can get a confirmation in next 1 block if you use a fee rate at 3 satoshi/ (v)byte for your transaction. Total size of mempool from the tip to 3 sat/ (v)byte is less than 1 MB.
If you are not in a hurry, wait for a few hours till around next 24 hours (or a bit longer), I think your transactions will get confirmations even at the fee rate of 1 sat/(v)byte. Check the mempool at https://jochen-hoenicke.de/queue/#1,24h
Happy holidays, everyone!
Edit for this small analysis.
If you are not in a hurry, wait for a few hours till around next 24 hours (or a bit longer), I think your transactions will get confirmations even at the fee rate of 1 sat/(v)byte. Check the mempool at https://jochen-hoenicke.de/queue/#1,24h
Happy holidays, everyone!
Edit for this small analysis.
I played with the data set today and I can confirm it.
Raw data
This part is for hourly fee, but for all days in this year.
- Each day, hours from 13 UTC to 22 UTC is the most terrible period to move bitcoin. Because its median of hourly fees are higher than median of all-24-hours each day from 2.4% to 33.9%. The rise begin since 12 UTC time.
- Each day, hours from 23 UTC to 7 UTC time are best to move bitcoin with cheapest fee.
- median_day: the median of transaction fee for all 24 hours every day.
- median_hrdate: the median of specific hour within each day
- diffpc = (median_hrdate - median_day)/median_day*100
Raw data
Code:
+-----------------------+
| rank hr diffpc |
|-----------------------|
1. | 1 13 33.91756 |
2. | 2 14 26.39759 |
3. | 3 16 24.86809 |
4. | 4 15 22.69867 |
5. | 5 18 22.69101 |
6. | 6 17 20.83675 |
7. | 7 19 17.3279 |
8. | 8 20 17.23884 |
9. | 9 21 3.767935 |
10. | 10 22 2.36229 |
11. | 11 12 .7935516 |
12. | 12 10 -1.17058 |
13. | 13 2 -2.019091 |
14. | 14 11 -3.211063 |
15. | 15 8 -4.933663 |
16. | 16 9 -5.961604 |
17. | 17 0 -9.296452 |
18. | 18 23 -9.901987 |
19. | 19 6 -10.01764 |
20. | 20 7 -11.85577 |
21. | 21 4 -11.99892 |
22. | 22 3 -12.54986 |
23. | 23 1 -13.05078 |
24. | 24 5 -18.52437 |
+-----------------------+
| rank hr diffpc |
|-----------------------|
1. | 1 13 33.91756 |
2. | 2 14 26.39759 |
3. | 3 16 24.86809 |
4. | 4 15 22.69867 |
5. | 5 18 22.69101 |
6. | 6 17 20.83675 |
7. | 7 19 17.3279 |
8. | 8 20 17.23884 |
9. | 9 21 3.767935 |
10. | 10 22 2.36229 |
11. | 11 12 .7935516 |
12. | 12 10 -1.17058 |
13. | 13 2 -2.019091 |
14. | 14 11 -3.211063 |
15. | 15 8 -4.933663 |
16. | 16 9 -5.961604 |
17. | 17 0 -9.296452 |
18. | 18 23 -9.901987 |
19. | 19 6 -10.01764 |
20. | 20 7 -11.85577 |
21. | 21 4 -11.99892 |
22. | 22 3 -12.54986 |
23. | 23 1 -13.05078 |
24. | 24 5 -18.52437 |
+-----------------------+
This part is for hourly fee, but for all days in this year.
Code:
Summary for variables: feeperkb
by categories of: hr
hr | N mean sd p50 p25 p75 min max
---------+--------------------------------------------------------------------------------
0 | 2140.0 34366.3 35900.9 20389.1 10648.9 47919.9 0.0 257092.0
1 | 2169.0 31738.9 32021.4 20497.5 11595.8 40873.2 0.0 256272.0
2 | 2144.0 35262.7 33591.5 23386.6 13155.4 47311.4 0.0 275091.0
3 | 2218.0 30540.3 30137.1 20669.0 11934.7 37680.5 0.0 280884.0
4 | 2139.0 30864.3 29414.5 20457.0 11769.6 40051.0 0.0 246312.0
5 | 2216.0 28780.9 27879.6 18980.7 11589.5 34882.8 0.0 303836.0
6 | 2097.0 31120.2 31085.3 20046.8 11515.5 39140.0 0.0 246045.0
7 | 2162.0 31728.8 30206.8 21364.8 12235.8 42497.0 0.0 247493.0
8 | 2184.0 34858.9 34490.9 21743.5 12173.4 46857.6 0.0 249996.0
9 | 2139.0 35982.9 34497.9 23887.9 12465.2 49436.6 0.0 232711.0
10 | 2150.0 36605.6 35136.4 23973.3 12366.2 49729.1 0.0 260038.0
11 | 2175.0 37262.3 35684.8 24664.1 12595.9 50795.9 0.0 250145.0
12 | 2146.0 40706.9 37370.8 28833.1 13489.4 56808.6 0.0 266947.0
13 | 2180.0 52372.6 42798.4 41836.3 19332.3 74290.4 0.0 340589.0
14 | 2132.0 47275.3 41043.6 34309.0 17192.5 67794.1 0.0 342649.0
15 | 2192.0 46111.7 39591.8 33790.2 16981.5 65084.8 0.0 279020.0
16 | 2183.0 48142.2 41745.7 33990.4 16798.3 70057.9 0.0 295485.0
17 | 2236.0 48759.5 43286.3 35645.0 16962.7 70143.3 0.0 309492.0
18 | 2170.0 47029.4 42725.5 32838.4 16265.4 67715.8 0.0 289470.0
19 | 2152.0 47406.2 43053.2 33724.3 15503.6 67292.0 0.0 272109.0
20 | 2185.0 45984.9 42112.1 31402.0 14616.1 66583.9 0.0 279584.0
21 | 2270.0 41938.1 39354.7 27447.0 12973.7 62083.4 0.0 307249.0
22 | 2181.0 41181.6 39385.3 27091.4 12695.9 57919.7 0.0 253167.0
23 | 2183.0 35448.4 35125.8 22265.8 11282.7 49712.4 0.0 252706.0
---------+--------------------------------------------------------------------------------
Total | 52143.0 39251.6 37543.7 25619.8 13231.9 55277.9 0.0 342649.0
------------------------------------------------------------------------------------------
by categories of: hr
hr | N mean sd p50 p25 p75 min max
---------+--------------------------------------------------------------------------------
0 | 2140.0 34366.3 35900.9 20389.1 10648.9 47919.9 0.0 257092.0
1 | 2169.0 31738.9 32021.4 20497.5 11595.8 40873.2 0.0 256272.0
2 | 2144.0 35262.7 33591.5 23386.6 13155.4 47311.4 0.0 275091.0
3 | 2218.0 30540.3 30137.1 20669.0 11934.7 37680.5 0.0 280884.0
4 | 2139.0 30864.3 29414.5 20457.0 11769.6 40051.0 0.0 246312.0
5 | 2216.0 28780.9 27879.6 18980.7 11589.5 34882.8 0.0 303836.0
6 | 2097.0 31120.2 31085.3 20046.8 11515.5 39140.0 0.0 246045.0
7 | 2162.0 31728.8 30206.8 21364.8 12235.8 42497.0 0.0 247493.0
8 | 2184.0 34858.9 34490.9 21743.5 12173.4 46857.6 0.0 249996.0
9 | 2139.0 35982.9 34497.9 23887.9 12465.2 49436.6 0.0 232711.0
10 | 2150.0 36605.6 35136.4 23973.3 12366.2 49729.1 0.0 260038.0
11 | 2175.0 37262.3 35684.8 24664.1 12595.9 50795.9 0.0 250145.0
12 | 2146.0 40706.9 37370.8 28833.1 13489.4 56808.6 0.0 266947.0
13 | 2180.0 52372.6 42798.4 41836.3 19332.3 74290.4 0.0 340589.0
14 | 2132.0 47275.3 41043.6 34309.0 17192.5 67794.1 0.0 342649.0
15 | 2192.0 46111.7 39591.8 33790.2 16981.5 65084.8 0.0 279020.0
16 | 2183.0 48142.2 41745.7 33990.4 16798.3 70057.9 0.0 295485.0
17 | 2236.0 48759.5 43286.3 35645.0 16962.7 70143.3 0.0 309492.0
18 | 2170.0 47029.4 42725.5 32838.4 16265.4 67715.8 0.0 289470.0
19 | 2152.0 47406.2 43053.2 33724.3 15503.6 67292.0 0.0 272109.0
20 | 2185.0 45984.9 42112.1 31402.0 14616.1 66583.9 0.0 279584.0
21 | 2270.0 41938.1 39354.7 27447.0 12973.7 62083.4 0.0 307249.0
22 | 2181.0 41181.6 39385.3 27091.4 12695.9 57919.7 0.0 253167.0
23 | 2183.0 35448.4 35125.8 22265.8 11282.7 49712.4 0.0 252706.0
---------+--------------------------------------------------------------------------------
Total | 52143.0 39251.6 37543.7 25619.8 13231.9 55277.9 0.0 342649.0
------------------------------------------------------------------------------------------
December 19, 2020, 11:20:43 PM
It was finally confirmed. For future reference, how much size is safe to get transaction confirmed within a few hours?
No one can give you an exact answers for all situations. it depends on mempool conditions that changes very fastly.Check mempool condition there: jochen-hoenicke.de
One hour means about 6 blocks and with that third chart, one block takes 1 MB (maximum from tip of the mempool). So one waiting hour will be roughtly 6 MB from tip of the mempool. It is applied for constant condition of the mempool. In reality, it is changing and what you can get is an estimation only.
As said, because of uncertainty of mempool, you always have to prepare for bad situations by turn on the RBF -- Replace-by-Fee for your transactions.
As of writing, 10:20 PM UTC time, 6 MB from tip of the mempool will be for the rate of 5 sat/ byte but not all waiting transactions at 5 sat/ vbyte will be confirmed all after next 6 blocks (even if mempool stays flat next one hour). Total size of waiting transactions with 5+ sat / vbyte is 8.615 MB.
December 19, 2020, 11:13:16 PM
Thanks for detailed response. Now the size for my fee rate is 24 MB. Is there a chance it would be confirmed this weekend?
It has decreased to about 15MB right now. If the mempool continues to clear at this rate [1], your transaction has a fairly decent chance of confirming within a few days. That is, unless the price of Bitcoin changes drastically and more people starts to sell again. [1] https://jochen-hoenicke.de/queue/#0,24h
December 19, 2020, 02:12:22 AM
Thanks for detailed response. Now the size for my fee rate is 24 MB. Is there a chance it would be confirmed this weekend?
It has decreased to about 15MB right now. If the mempool continues to clear at this rate [1], your transaction has a fairly decent chance of confirming within a few days. That is, unless the price of Bitcoin changes drastically and more people starts to sell again. [1] https://jochen-hoenicke.de/queue/#0,24h
December 19, 2020, 12:08:10 AM
My transaction ...... is stuck since 2 days even though I sent with 17 sat/byte fee 
It will be stucked for a while. As of writing, from the tip of mempool to the fee rate you used, total size is about 51 MB. If you are lucky, that transaction will be confirmed in the coming weekend. If you are unlucky, you will have to wait till the next weekend. The second scenario is what I guess you will have. - Good thing: the fee rate is high enough to help your transaction get confirmation after a while of waiting.
- Bad thing: it is marked as NO Replace-by-Fee so that you can not boost the transaction (if you sudden are hurry).
- Lesson from it: Try to use a non-custodial wallet and turn on the RBF option. It helps you to replace and boost your transaction with higher fee
December 18, 2020, 05:09:04 PM
^Yup, using ETA was the problem I guess so fellas can use Mempool option and move the bar to your desired state. Maybe we can see Mempool size getting decrease a bit so this weekend maybe the best time for anyone to move funds because again the coming monday we can see huge traffic in the mempool again either if there is surge or dump in bitcoin's price
December 18, 2020, 03:08:41 AM
Yes I had been using the default one which is ETA, is the only thing giving inaccurate calculation? But I am not sure about it.
Since when I found they are giving over killing fee, I moved to the website which I mentioned and it is easier for me to set the required fee using static feature which is the second one after ETA guess. Mostly I won't make any transaction when the network is congested so static works fine for me.
It is your problem, as said.Since when I found they are giving over killing fee, I moved to the website which I mentioned and it is easier for me to set the required fee using static feature which is the second one after ETA guess. Mostly I won't make any transaction when the network is congested so static works fine for me.
ETA method gives you the estimate fee that your transaction will probably be confirmed within X blocks. Default, X is 5 blocks. You can change the X parameter by slip the bar through 5 values: 25, 10, 5, 2, and 1 block(s).
If you look at the mempool with https://jochen-hoenicke.de/queue/#1,24h or see screenshot above. When mempool is flat between fee rates, ETA will give you over killing fee. It gives you acceptable fee rate if mempool is stucked.
December 18, 2020, 02:59:41 AM
I don't know what caused your problem with inaccuracy from fee rate estimate in Electrum (wallet for Android). As I emphasized, make sure you choose the Mempool option for your mobile wallet. Default, the wallet is use ETA for fee estimation that often gives you over killing fee. Is it the option you have on your mobile wallet?
Yes I had been using the default one which is ETA, is the only thing giving inaccurate calculation? But I am not sure about it.Since when I found they are giving over killing fee, I moved to the website which I mentioned and it is easier for me to set the required fee using static feature which is the second one after ETA guess. Mostly I won't make any transaction when the network is congested so static works fine for me.
December 17, 2020, 11:30:40 PM
My transaction ...... is stuck since 2 days even though I sent with 17 sat/byte fee
It will be stucked for a while. As of writing, from the tip of mempool to the fee rate you used, total size is about 51 MB. If you are lucky, that transaction will be confirmed in the coming weekend. If you are unlucky, you will have to wait till the next weekend. The second scenario is what I guess you will have. - Good thing: the fee rate is high enough to help your transaction get confirmation after a while of waiting.
- Bad thing: it is marked as NO Replace-by-Fee so that you can not boost the transaction (if you sudden are hurry).
- Lesson from it: Try to use a non-custodial wallet and turn on the RBF option. It helps you to replace and boost your transaction with higher fee
December 17, 2020, 11:23:00 PM
My transaction https://www.blockchain.com/btc/tx/d19e3452d7695d49eaf4aeae3bb65c7412770ee6b1ffdf583d21fb8d541b7da7 is stuck since 2 days even though I sent with 17 sat/byte fee
Jump to: