Search statistics about necessary transaction fees within the next x blocks?

[pxstein]

In order to better estimate the necessary transactions fees when sending BC I am searching for backward statistics over the last month resp resp last year.

How much BC/sat do users had to spent to get a transaction executed within the next x Blocks?

Is there somewhere a statistic chart showing this for the last months?

Thank you

[Charles-Tim]

It is BTC not BC if you are referring to bitcoin.

These threads would be if help:
Minimizing bitcoin transaction fee
List of Bitcoin Mempool Viewers for Reference
Bitcoin Transaction Fees - Everything in one

For mempool viewer, you can use https://mempool.space/ for beginners or https://jochen-hoenicke.de/queue/#BTC,24h,weight for advanced users.

Know that fee is in satoshi/vbyte not BTC/satoshi.

[LoyceV]

https://jochen-hoenicke.de/queue/#BTC,24h,weight for advanced users.

This is what I use: hover your mouse on the right edge, and see how much data is waiting at each fee. At the moment I would use 1 sat/vbyte + a few sat. So for a one input one output transaction, I use 118 instead of 111 sat. And just in case, keep RBF as an option.

Note that fee estimates are based on past blocks, while the fee you have to pay is based on future blocks. It's always a bit of a gamble.

[hosseinimr93]

Is there somewhere a statistic chart showing this for the last months?

If you want to see the history of the required transaction fee, I think the best option is jochen-hoenicke website.
Set the period at top of the page and move the mouse pointer to see the mempool condition in different times.

The tool displays size of unconfirmed transactions in the mempool at different fee rates.

Let me explain how the tool works with an example.
Look at the image below. (Note that this is just an example and doesn't show the current condition of the network.)



According to the data shown in the above image:
There are 17.7 vMB of transactions paying at least 1 sat/vbyte.
There are 15.6 vMB of transactions paying at least 2 sat/vbyte.
There are 15.0 vMB of transactions paying at least 3 sat/vbyte.
There are 13.9 vMB of transactions paying at least 4 sat/vbyte.
........
........
........

Any block can include up to 1 vMB of transactions.
So, assuming the size of unconfirmed transactions in the mempool is as shown in the above image, the required fee for getting confirmation in the next block is 15-17 sat/vbyte.  
Of course, the network isn't that congested now and as mentioned by LoyceV in the above post, 1 sat/vbyte should be enough now.

Note that the required fee is dynamic and can change over time.
There is no way to guarantee that a transaction will be confirmed in the next block.

[o_e_l_e_o]

In order to better estimate the necessary transactions fees when sending BC I am searching for backward statistics over the last month resp resp last year.

I would just expand on the answers above by saying that statistics on fees over the last month or year are going to be next to useless when estimating what fee to pay now. The mempool fills and empties so frequently that an appropriate fee could go from 1 sat/vbyte to 50 sats/vbyte several times over a single day, and a sudden and unexpected price swing can cause the mempool to rapidly fill up without warning. You could look at the last 6 months of fees and decide that 1 sat/vbyte is sufficient just as the mempool is filling up and your transaction could sit unconfirmed for days or weeks. Similarly, you could look back at a month of high fees and end up paying far more than you need to when the mempool is already emptying.

When choosing a fee to pay (if I'm not happy to just pay 1-2 sats/vbyte and wait patiently as I usually am), then I'll generally look back over the last 6-12 hours at most to see the general trend of the mempool - filling, emptying, or static. That knowledge, combined with the current size and fee of unconfirmed transactions, is enough to make an educated decision. Months of data is pointless.

[Lucius]

With everything already written, I would just add that it is always wise to have the ability to RBF (replace by fee) in the crypto wallet we use. I was often very careful and followed what was going on in mempool before I made the transaction, but then it happens that I have bad luck and there is no new block 40 minutes or even 60 minutes. Then the mempool is filled with transactions and if we paid a very low fee, it can mean hours of waiting for the first confirmation - which can be very inconvenient if we paid something in a physical store or even online if the seller has a certain period of time asking for the transaction to be confirmed.

This feature is always great insurance if something unforeseen happens, of course assuming you have enough funds in the wallet for a bump fee

[NeuroticFish]

In order to better estimate the necessary transactions fees when sending BC I am searching for backward statistics over the last month resp resp last year.

If you want to estimate the fees you need for a transaction, looking for months old data will get you nothing useful.
You can web search for average fees chart bitcoin and you may get the data, but again, it won't help.

As the others said, you have to look on https://jochen-hoenicke.de or https://mempool.space/ since they will give you an image on what is now in the mempool. And that is most probably unrelated to what was there one week or one month ago.

Then you can decide based on:
* how full mempool is
* what fees others have used in current mempool (the competition)
* how fast the last blocks got mined
* the difficulty vs hash rate (eg if the percent in mempool.space for estimated diff adjustment is >0 then you have to expect faster-than-usual blocks)
* whether you expect the number of transactions-to-come increase or not in the near future

As you can see, all these are basically unrelated to whatever has happened in the past, especially week(s) ago.

[pxstein]

Ok, thank you very much for the helpful comments.

One more question about calculating the necessary vBytes.

Just to clarify what I read and understand so far from other webpages:

If I want to send BTCs from my Wallet (in Legacy Mode) and
I send BTCs from x own addresses to y partner addresses and get back the change on 1 more own address I will have to pay for

x * 149 + y * 34 + 1 * 149 +-10 =  .... vBytes

Correct?

[hosseinimr93]

I send BTCs from x own addresses to y partner addresses and get back the change on 1 more own address I will have to pay for

x * 149 + y * 34 + 1 * 149 +-10 =  .... vBytes

Correct?

First of all note that the transaction fee depends on number of inputs, not number of addresses you spend from.
Assuming you have received 5 transactions in a single address and now you want to spend all the fund, your transaction sill has 5 inputs.

Secondly, when it comes to calculating the transaction size, there is no difference between the change address and the recipient's address. Each of them adds a same size of data to your transaction.

[o_e_l_e_o]

Just plug your numbers in to this calculator instead of trying to do it manually: https://bitcoinops.org/en/tools/calc-size/

For legacy (P2PKH) transaction, each input is 148 bytes and each output is 34 bytes. The owner of the output is irrelevant; whether you are sending coins to someone else's address or back to your own change address, the output will still be 34 bytes.

[nc50lc]

-snip-
Is there somewhere a statistic chart showing this for the last months?

I see that you've moved this specific question from your other topic into its own thread.
I already got an answer in that thread, I'll quote it here if you missed it:

-snip- you can select another slider option in the drop-down menu of the 'send' dialogue box:
From 'ETA', 'mempool' and 'static';

• ETA: the default with most accurate estimate (but most of the time over-estimates)
• mempool: for advanced users who can understand how mempool works; usually, it's "1~0.5 MB from tip" as the 'express' fee rate.
• static: the basic slider with pre-configured values from 1~300sat/vByte.

The absolute fee is displayed above as "Mining fee", but the prioritization is based from the "fee rate" (slider).

Why do you have to calculate and research just to send a transaction with "necessary transaction fee"?
Your wallet already got that covered so you don't have to go to web for statistics and calculate in order to find the optimal fee.
Amongst the options, I'd suggest you to use "mempool" and use 1~0.5mb from tip (displayed when you hover-over the slider).
Personally, my technique is: Open the 'Advanced' tab, set the fee rate slider to '1mb from tip', then edit the absolute fee by a few satoshi higher so it'll be just below the tip.

Overall, no can can really estimate if the next block will be mined quickly after you broadcast the transaction,
the mempools can grow in size during that time making your "optimal fee rate" drop out of the priority.

[pooya87]

x * 149 + y * 34 + 1 * 149 +-10 =  .... vBytes
Correct?

This is a very simplified equation that only works for very simple cases with legacy inputs and outputs. Things are much more complicated when it comes to calculating transaction sizes these days and it mainly depends on the type of the output that is being spent. There should at least be 20 equations or better yet a library that would compute serialized size on demand.

[pxstein]

First of all note that the transaction fee depends on number of inputs, not number of addresses you spend from.
Assuming you have received 5 transactions in a single address and now you want to spend all the fund, your transaction sill has 5 inputs.

As I learned (even from this forum) no one should send BTCs to the same address more than one time.
So how can it happen that there is more than 1 input per address?

The only situation I can think of is when it took place accidentally or by inexperience.
So normally (in 99%) all send addresses count as 1 input.

Am I correct?

[o_e_l_e_o]

As I learned (even from this forum) no one should send BTCs to the same address more than one time.
So how can it happen that there is more than 1 input per address?

Because although you shouldn't do it for privacy reasons, there is nothing at a protocol level to stop you from doing it. Lots of people reuse addresses many times, and so will end up in with multiple inputs on the same address. In some specific circumstances you can reuse addresses without losing too much privacy, for example, if you are receiving multiple payments from the same person over a period of time. In such a case you still reveal the total amount you have received, but you at least avoid linking it to payments received from other sources. Lots of big services and exchanges reuse the same hot wallet addresses thousands or even millions of times.

The only situation I can think of is when it took place accidentally or by inexperience.
So normally (in 99%) all send addresses count as 1 input.

Accidentally, inexperience, using a bad wallet that doesn't generate new addresses, doing so out of convenience while accepting the risks involved, etc. There are lots of reasons. It is far higher than 1% of addresses which are reused.

[BlackHatCoiner]

The only situation I can think of is when it took place accidentally or by inexperience.

There are few cases where address reuse facilitate. Take for instance, payments from the same person on a regular basis (e.g., signature campaigns). Or donations; it's far easier to just leave a donation address instead of creating a new one each time for each visitor.

I don't say that it's recommended or that it provides the same privacy whether you reuse or not the same address in these cases, but it definitely facilitates to reuse.

[Pmalek]

If you are planning to perform coin consolidations sometime in the future, it won't matter much if you used new addresses for each payment you received or if you generated a new one every time. Once you consolidate all those inputs into a single one, there is digital proof that all inputs and addresses belong to the same person who signed for the coin consolidation to take place.

[ranochigo]

As I learned (even from this forum) no one should send BTCs to the same address more than one time.
So how can it happen that there is more than 1 input per address?

Not recommended but it is fine.

The only situation I can think of is when it took place accidentally or by inexperience.
So normally (in 99%) all send addresses count as 1 input.

Am I correct?

Bitcoin doesn't work by an account system but each inputs have different conditions to be spent. Addresses are just a more simplified representation of the UTXOs associated with a certain keypair; addresses are derived using the public key.

You don't have to look at the mempool statistics if you want a general idea of how much fees you'll be paying regardless of future events or conditions. Looking at the composition of fees within the historical blocks would suffice.

[pxstein]

Thank you for comments