Topic: How do we calculate the correct transaction fee to send? (Read 515 times)

Users have previously mentioned that it's entirely not based from the amount.

If your comment is based from self-experience, it's most likely that you have multiple inputs with small amounts that it would take 2 or more inputs to fulfill the high amount you've inputted.

e.g.: Let's say you've received 0.0001, 0.00011 and 0.00012 BTC before that aren't consolidated into 1 UTXO.
If you need to send 0.00009 BTC; it will only have to use 1input, thus smaller transaction size and lower fee.
If you need to send 0.0003 BTC; it will have to use all three inputs, thus higher transaction size and higher fee.

There are various wallets/exchanges that provides you the estimated or even the exact transaction fee, one example for the wallet is Mycelium. The transaction fee is based and calculated through the amount you have inputted, the priority of the transaction that you selected, and the current state of the mempool, particularly, the traffic.

Sites will generally give a suggested fee rate, rather than an absolute fee. The fee rate should be in the format of sats/vbyte. This is how much satoshi you will pay for each virtual byte of space your transaction takes up. The number of virtual bytes a transaction takes up is dependent on the number of inputs, the number of outputs, the exact type of those inputs and outputs (legacy, segwit, etc), and a few other factors.

For example, if your transaction was 2000 vbytes and you paid 1 sat/vbyte, you would pay 2000 sats. Your transaction would be right at the bottom of the current mempool, since miners care more about the fee rate than the absolute fee.
If your transaction was 250 vbytes and you paid 8 sats/vbyte, you would also pay 2000 sats, but this time your transaction would be much nearer the top of the current mempool.

A transaction moving 10 bitcoin could involve 1 input and 1 output and therefore be as low as 110 vbytes in size, or it could involve 100 inputs (or more) and be thousands of bytes in size. It all depends on across how many inputs that 10 bitcoin is spread.

Note that transaction fee doesn't depend on the amount you send. So, it doesn't matter whether you are sending 1000 BTC or 1000 satoshi.
When you make a transaction, you should set the fee rate according to network state and how fast you want your transaction to be confirmed. The total fee depends on number of inputs and outputs and address(es) type as well. You can use bitcoindata.science (a tool created by the forum user, bitmover) to calculate the total fee based on number of inputs and outputs, your address type and the fee rate.

isn't there a simple site where you can input few data and it gives you an estimated transfer fee?  I want to know how much it costs to transfer 10 Bitcoin from 1 wallet to another wallet.

point taken, it wouldn't normally be relayed by nodes. however, that just means the spender needs to send the transaction to miners out-of-band.

such transaction won't even be relayed as it would be non-standard so it doesn't exist in 99.9% of the node's mempool. the only way to see something like this is for a miner to both create this transaction and mine it in which case there is no need to pay any fees.

there are edge cases where we could theoretically get very close to 4MB. https://bitcoin.stackexchange.com/a/54949


in practice, miners would ignore such transactions unless they paid ridiculously high fees. so it doesn't happen.

A block (at present) can never contain 4 MB worth of transactions.

The limit on a block at present is 4,000,000 weight units. See my reply on the previous page for a brief explanation of what weight units are. Legacy transactions are only non-witness data, so take up 4 weight units per byte, and a block could fit a maximum of 1 MB. Witness data takes up 1 weight unit per byte, so if a block contained nothing but witness data, it would be 4 MB.

There are no transactions which are just witness data, though. SegWit transactions contain both non-witness (at 4:1) and witness (at 1:1) data. A block filled with regular SegWit transactions and no legacy transactions has an upper limit of somewhere around 2.5 MB. The biggest block we've ever seen so far was block number 566575, at 2.377 MB.

I use electrum wallet and usually I drag the cursor to left to set lowest fee, then click preview and you can see how many bitcoins are being deducted as fee. I don't know about other wallets.

It's not because some people pays higher fees or some pays lower. If someone needs faster confirmation, they are likley to pay higher fee. Since we have limited space on block (4MB per block now), if there are a lot of transaction pending, you are likely to pay the maximum fee for faster confirmation if you are in hurry because only limited number of transactions will get place in the block (~4MB). That's how fee increase and decrease. No one is likely to pay higher fee unless they need to.

Perfect! It means most of bitcoin transactions have been made in America and European continents and locals there tend to use higher fees (likely), whilst the Asia and Australia continents tend to make less numbers of transactions as well as they likely are ready to move their coins with lower fees.

A bigger contrast is seen at times of the day. Go to https://jochen-hoenicke.de/queue/#1,6m and zoom in (by selecting an area on the graph) on a random week or so in the last few months. Generally when you see a surge in the mempool size, and therefore the average fee, it is usually around 13:00 - 23:00 UTC, which corresponds to day time in most of Europe, and initially the east coast and then all of the Americas. Conversely, the mempool is usually fairly empty, with fees around 1-2 sat/byte, around 01:00 - 06:00 UTC, when the aforementioned continents are generally sleeping and Australia and eastern Asia are awake.

You can use this to your advantage to plan non-urgent transactions, such as consolidating all your small inputs.

LOL well I never went to check exact numbers but saw it just by looking at mempool graphs. And we of course usually look at mempool when is more full then usually   At those times difference is for sure bigger.

So, the simple answer here is that coinb.in/#fees is stating the fee in sats/vbyte, although they call it sats/byte. We can tell this because the transaction sizes they show are different for legacy and SegWit transactions.

The longer answer is more complicated, and there is no straightforward way to "convert" between the two, since it depends entirely on the particular transaction you are looking at.

Plain bytes are not used to measure the size of transactions anymore, since the SegWit soft fork. Instead we use weight units. You can read more about these here: https://en.bitcoin.it/wiki/Weight_units. Essentially, insteading of blocks being able to hold 1 million bytes, they now hold 4 million weight units. For legacy transactions, each byte takes up 4 weight units, so the effective size of these transactions doesn't change. For SegWit transactions, however, the witness data only takes up 1 weight unit per byte, so the effective size is smaller. To prevent having to multiply and divide by 4 all the time, lots of people instead use virtual bytes or vbytes, which again, are equal to 4 weight units. So a block can contain 1 million vbytes.

This means that for legacy transactions, 1 byte of transaction data takes up 1 vbyte on the block, but for SegWit transactions, 1 byte of witness data will only take up 0.25 vbytes of block space (the non witness data is unchanged, and still takes up 1 vbyte per byte). This makes SegWit transactions take up less block space, and therefore, cost less in fees.

Now for some examples. Take a look at this legacy transaction: https://blockchair.com/bitcoin/transaction/b74c4d36e9835923556b34f53fead7c9d51c03435e80805a2c8b904852a8a35f

You can see its size is 224, and its weight is 896, which is exactly 4 times its size. This is because it is a legacy transaction. Its fee per vbyte and fee per byte are the same.

Now look at this SegWit transaction: https://blockchair.com/bitcoin/transaction/dcddd311deb7c4a4a2b63b10bc762badc7a0fcefd7afc336838cc2f57e326360

It has a size of 374, but its weight is only 1,169, which is about 3.1 times its size. Its fee per vbyte is higher than its fee per byte, because some of the bytes (the witness data) are "discounted" as explained above.

Thank you. I did not realize that importance. The number of transactions and sum size of transactions in membpool are very different, and the difference play important role to consolidate coins, especially if people consolidate their coins with low fees.

By the way, could you help me with the conversion of fees from satoshi/ byte to satoshi / vbyte, please.
The difference between: https://coinb.in/#fees and https://btc.com/stats/unconfirmed-tx, then how to make conversion?

You made me curious about transaction fee in different days of week.
I calculated the average transaction fee for different days of the week in the past three months. (Raw data from https://bitinfocharts.com/)

Monday: 0.70 $
Tuesday: 0.70 $
Wednesday: 0.71 $
Thursday: 0.71 $
Friday: 0.74 $
Saturday: 0.63 $
Sunday: 0.57 $

You were right. I hadn't ever noticed this.

Not directly related, but you mention not urgent transaction. I noticed that usually mempool gets fuller towards end of the week and empty over weekends. So cheapest day to send a transaction is Sunday. Or the fastest day to send cheap transaction.

This a poor graph to use to visualize the mempool in the context of working out a fee. A better choice is the third graph on Johoe's site here (https://jochen-hoenicke.de/queue/#1,8h) entitled "Mempool Size in MB".

The reason for this is because the graph you linked to shows the number of unconfirmed transactions, whereas the graph I've linked to shows the size in MB of these unconfirmed transactions. Why is this important? I'll use two examples to illustrate my point. Lets say first of all that the mempool contains 10,000 transactions, but each transaction is less than 250 vbytes in size. This means the mempool is actually relatively empty at only 2.5 MB, and could completely empty in only 3 blocks. Conversely, lets now say the mempool contains only 1,000 transactions, but they are all huge consolidation transaction from various exchanges, and each one is 30,000 vbytes in size. Now the mempool is the fullest it has been in months at over 30 MB.

So using the graph you linked, if we see 1,000 or 10,000 transaction, we don't actually know how full the mempool is because we don't know the size of those transactions, which is what actually matters. Blocks are limited by size, not by number of transactions. A block could contain anywhere from 0 to over 4000 transactions.

The size of the fee depends on many factors, including the conditions of the wallet that you use. Everywhere conditions are different. Therefore, first of all, study the conditions of your wallet or better ask your wallet support to write everything in detail. Sometimes it’s a lot easier than figuring it out yourself!

OP can take a look at my topic: Bitcoin Transaction Fees - Everything in one
You can check the estimated fees on https://coinb.in/#fees to see good fees you can set for your transaction at each time. For example, if the suggested fee is 1 satoshis, I advice you to set your fees at 2 or 3 satoshis in order to make sure that your transactions will be confirmed faster whilst there is not much more additional fee between 1 and 3 satoshis/ byte.

This one: https://whatthefee.io/ gives you the table with the probability to get confirmations with each level of transaction fees.

In order to make sure that you choose the right time to move your coins, take a look at mempool: https://www.blockchain.com/charts/mempool-count?timespan=60days. Don't move your coins when mempool shows spikes.

you search for a wallet that is developed by a competent developer so that it can calculate the correct transaction size and then sets the appropriate fee based on your selection of "priority level" not fee itself.
seriously though, you shouldn't try to calculate transaction size and fees on your own. there is a very good chance you will mess it up and stay away from website such as bitcoinfees.earn.com they are horrible at suggesting fees.

my suggestion is Electrum. it is doing a pretty good job and it is user friendly. all you have to do is to enable the fee slider and the more to the left is less priority and the more you pull it to the right you get higher priority.

if you want to know the technical details of how size (or rather weight) is calculated then it is a different question. for that you'll need some prior knowledge of transaction structure, scripts, signature hash types, and serialization of transactions for signing with each different script type. and depending on each script type you'll get a different size and weight and depending on what crypto library is being used you may get fixed length signatures or with 1-2 byte difference which you need to account for when setting the minimum fee.
i can explain each details of it if you want but it will be tedious and may not be what you are looking for.

Agreed, and edited my post.

If you spend one or more of the inputs from the original transaction, the entire original transaction will become invalid. If the original transaction does not confirm after a couple of days, most nodes will 'forget' about your original transaction and will accept a new transaction with the same inputs, but if you do not spend one or more of the inputs, the transaction will forever remain valid.

This really only matters if you send coin to a new wallet, the transaction doesn't confirm and you lose the private keys to your new wallet.

No there's no way to cancel unconfirmed transaction it will just be rejected by the nodes it is not likely the same as you make a transaction offline where you can just delete the transaction and make a new signed transaction.
Based on my experience before with Electrum my unconfirmed transaction for almost a week it gets rejected and the transaction will be gone in the transaction history. So if you don't have the raw transaction you can't rebroadcast them again but if you have a copy of raw transaction you can rebroadcast it.

Anyway, If your transaction gets rejected you can make a new transaction again as normal as sending. If you don't want the transaction gets rejected always check the recommended fee from coinb.in or bitcoinfees.earn.com Because if the recommended fee increases and you pay 1sat/byte there is a big chance that your transaction will be rejected again. That is why it's recommended to use the recommended fee from Electrum.

Wow, so there is no way to cancel an unconfirmed transaction even after say 2 weeks of it being unconfirmed? What happens then? How to get it on the blockchain later?

That's because some of these sites will only show estimations for transactions involving legacy Bitcoin addresses.

Oh thanks a lot for that advise! I will check it out. Learning every day! 

+1 for Johoe's site. It's the only site I use for deciding what fee I want to pay. There is a great guide on how to understand and interpret the graphs on 1miau's post here: https://bitcointalksearch.org/topic/make-sure-to-avoid-wasting-btc-for-too-high-fees-step-by-step-guide-electrum-5182906 (scroll down to item 5).

Every site which tells you a fee is using some sort of automatic algorithm. Sometimes they are quite accurate, other times they are not. Only you know how urgent or not your transaction is, and it's far easier to see if the mempool is filling up or emptying if you eyeball it yourself. If you really just want a site to tell you a fee to pay, then pick https://www.coinb.in/#fees.

The transaction will almost always confirm eventually, you might just be waiting a couple of days. In the event that the mempool becomes very full and your transaction has a very low fee, it will eventually be dropped from all nodes and you can simply try to spend the coins again. If you use a wallet like Electrum, you can enable a feature called RBF or Replace By Fee - with this enabled, if your transaction is taking too long to confirm, you can boost the fee to have it confirm faster.

This site is only useful if you look at the charts yourself. Their suggested fee at the bottom is usually way too much unless you absolutely need to get in to the next block. At the moment their suggest fee is 22 sats/byte, which would put you around 0.05 MB from the tip of the mempool.

yes, here is an in-depth breakdown of how transaction size is calculated: https://bitcoin.stackexchange.com/a/92700

this definitely isn't the simplest way though. a good wallet like electrum will show you the actual transaction size in bytes and allow you to choose the fee rate in satoshi/byte. https://bitcoin.org/en/wallets/desktop/windows/electrum/


i didn't know coinb.in had a fee estimator. it's a tad frustrating that they include bech32 as an option for inputs but not outputs. it makes a difference due to the segwit discount. the lowest possible recommended fee on coinb.in is 0.00000144 BTC but it should be closer to 0.00000110 BTC.

my preference is for Jochen Hoenicke's fee estimator. great visualization for estimating different priority times, ie next block vs within 8 hours, etc: https://jochen-hoenicke.de/queue/#0,24h

There are various sites that use various algorithms to estimate the required fee to get your transaction included in a block. I would suggest https://bitcoinfees.earn.com/ that is both simple and gives you enough information to estimate how large a fee to include depending on how quickly you want your transaction to confirm. /edit - you should review the chart to decide how much to pay for your transaction fee

To answer your other question, yes you can include a very small fee and it might take a long to for your transaction to confirm if it ever does. After several days, most nodes will ‘forget’ your transaction if it doesn’t confirm but it will remain valid as long as all the inputs remain unspent. This means someone may broadcast your transaction long into the future if it is still valid. This means you should keep your private keys, including backups if you ever even try unsuccessfully to send coin between wallets.

I've tried Earn.com and the ones you mentioned before, and I found all of them to be overestimating fees. I suggest this one, it's far more accurate: https://coinb.in/#fees

A very interesting article concerning Bitcoin transaction fees can be found here: Bitcoin Transaction Fees Explained [Complete Guide]

Websites to calculate the optimal Bitcoin transaction fees are e.g.:

https://Estimatefee.com "is a simple website that calculates the cost (in satoshis and USD) for a bitcoin transaction based on how much of hurry you are to move your coins from A to B."

https://Bitcoinfees.info "displays slow/medium/fast fees in USD with no muss and no fuss."

Source: https://bitnewsbot.com/how-to-calculate-bitcoin-transaction-fees-when-youre-in-a-hurry/

If you are not in a hurry, just set 1 sat/byte and it will be confirmed in a few hours
 Last week a sent a transaction like this that was confirmed in about 8 hours.

To see how much your transaction will cost, take a loop here:
https://www.buybitcoinworldwide.com/fee-calculator/

It will depend on:
Number of inputs
Number of outputs
Type of address (segtwit or legacy)



Before you ask:
Inputs are generated each time you receive btc. For every btc transaction you receive,  you have a new input. The more inputs, the more expensive the transaction.
Outputs are how many destination addresses.  Usually you will need 2 (one for destination and one for the change, back to you)

If you have a input of 0.5 and want to transfer 0.1 btC, you will receive 0.4 back in a change address.

You can consolidate your inputs when fees are low, at 1 sat byte. Take a look here
https://bitcointalksearch.org/topic/aug-2022-mempool-empty-use-this-opportunity-to-consolidate-your-small-inputs-2848987

What's the simplest way of calculating the optimum fee? For 'Satoshi per byte', is it possible to know how many bytes the transaction is likely to take?

Also, suppose the transaction is not urgent (say changing BTC between own wallets or sending to a relative), can it be sent with very low fee? What's the worse that can happen - will the transcation get cancelled/not go through on the blockchain?

Thanks!