Topic: How to calculate bitcoin transaction size and fees (Read 568 times)

There are many ways on how we can calculate these things but the best way is to use Crypto Calculator, as this just simplifies everything for everyone.

It just ensures that we are able to work nicely and easily without any major trouble at all. With this we can easily do well and able to get the right calculation, especially if we are dealing and doing transaction is bigger numbers. It’s almost necessary for everyone to get this right.

To be clear: it seems to me that general formula is fee = size x (satoshies/byte) but  I wanna have formula for size when various inputs (legacy and segwit) are combined into single transaction.

For controlling the fee, I guess, you don't need to know the mathematical formula. However, the formula is for calculation of transaction size, not for the fees. Fees can be found at your pointed web, you can pay less or more, it's your choice.

Well, but one can combine various  inputs from both legacy and segwit (p2sh, bech32) addresses into one transaction. Does anyone know how to calculate the transaction fee in this case? Is there any formula to do that? I have asked this question in Russian section and they pointed me to https://coinb.in/#fees  site that could help in estimation. Regardless,  I would like to  have the reliable   mathematical formula to control the fee.

I just remembered something which is related to the subject of having many inputs.

Electrum allows you to chose which input to use. There is an option "coins" which let's you see all your inputs and choose which one to spend. This is particularly interesting to do if you have many inputs, because you can consolidate as many as possible in a transaction of fees are low, or use the minimum as possible of they are high.

Remember that any additional BTC will become a new input that will go to a change address.

It will get confirmed pretty soon. The mempool is pretty much empty and 1-3 blocks would clean it up to 2-3 sat/byte transactions.

I think this is the best website to visualize the state of the mempool and see that: https://jochen-hoenicke.de/queue/#1,2h

I use Electrum and rarely use their suggested fees unless I am in a hurry.
I am sending bitcoins to myself from a non segwit to a segwit address and I paid only 5 sat/byte as I don't really care when it will get confirmed.

I think this will be great.
Research more about the subject and expand your OP.

I did that with https://bitcointalksearch.org/topic/summary-of-proof-of-work-3317586

I read a lot about it and wrote. Then many users explained a lot of things to me that I wasn't aware and I updated it. Later on I read more about it and made new additions. You can do it here.


I experienced this as well.

I usually search about 3-4 websites before making a transaction.  usually I use a lower value than suggested.

I noticed that Electrum suggests a fee as well when you are about to make a transaction (and they were lower than those websites).. Few months ago I made transactions with 1 sat/byte that wwere confirmed in less than 1hour, and most of those websites were suggesting more han 10sat/byte.

it is not just legacy and SegWit, it is also compressed and uncompressed public keys and also multi signatures both in SegWit outputs (2 types) and in legacy outputs (1 type). which depending on their number of signers the size can be very different. before the year ends we may even see new signatures (Schnorr) and end up with a new transaction size based on them!

it is good to learn but it is best to try and post things as a question.

My bad, I am fairly new in this space and had no idea that fee can vary for legacy and segwit address. Had no idea for more input, I have to pay more fee. I got another thread about future fee of bitcoin transaction and this question peek at my mind that how fee is actually calculated. I was redirected to an article, was probably an old one which had referred to this method only.
Anyway, this is help and beginners board, beginners can do some mistakes. I guess members like you will always help beginners to understand the system, this is why a forum is the best place to learn.
I will update the topic with more information.
Thank you.

please don't create incomplete guides like this one here with a misleading formula. what you have found on the internet belongs to many years ago where bitcoin only had 1 type of transactions with 2 type of public keys (compressed and uncompressed) nowadays there are more variations and that formula is so complicated that you better leave it to your wallet to automatically calculate it for you.
of if you want to post a guide then do it completely by including all the possible cases with different types of input/output. and keep in mind that fees are no longer measured in satoshi/byte but instead in satoshi/virtualByte

also please don't suggest bitcoinfees.earn.com (https://bitcointalksearch.org/topic/m.30657510)


it is because the day Satoshi created bitcoin he decided to use a third party library for signature stuff. this library is the OpenSSL library. there the encoding used for signatures is a wasteful and in one word stupid encoding for something like bitcoin.
to keep it simple here is how it works:
when you create an ECDSA signature you basically have 2 n-bits integers (256 bit for bitcoin's curve) in this particular encoding, on top of other wasted bytes you sometimes have to add an additional byte (=0) to the start of these integers to tell everyone reading the encoding that the numbers are positive. so sometimes you end up with
(some other bytes) + 1 + 32 + 1 + 32 or
(some other bytes) + 0 + 32 + 0 + 32 or
(some other bytes) + 1 + 32 + 0 + 32 or
(some other bytes) + 0 + 32 + 1 + 32
hence the +-2

which again brings us back to the first line of this comment! nowadays the second number is changed for some reasons (outside of the scope of this topic) so it will always be smaller than 32 byte. and there is a much newer change which also changes the first number so that it is 32 bytes (in some implementations such as bitcoin-core) so you will always end up with the same 32 byte size hence a fixed signature size.

yes, your calculation works only for non-segwit inputs specifically utxo from uncompressed legacy addresses
for non-segwit compressed legacy you simply replace 180 with 148
checkout coinb.in's fee calculator that was mentioned by LoyceV in the post above
it should give you estimate size on almost all different possible inputs, except bech32

I guess I too use this one as source in the OP, you probably have missed that part.

My pleasure. Thank you anyway.

Please link me toward the calculation of Segwit and bech32 segwit transaction size calculation. Interested to learn it.

Your formula is only accurate for non-segwit (and non-multisig) inputs.

A SegWit input will take up 91 bites and a bech32 input (a different type of SW address that starts with “BC1”) will take up 68 bites of block space after accounting for the witness (signature) discount.

Yes this site made me people lazy LOL (especially me). Until today I did not have this mind how byte size calculation works. All those days I only played with the sat/B field.

Thanks OP. It was useful more me 🙂 I left you some reward. Enjoy your 50 merit mark.

Check this formula below I just got it from google when searching images.

Thank you but it was an initiative of learning the process how it actually get done.

It should be 474/470 bytes. My initial calculation was wrong. I guess you got it now.

There's a much easier solution: use https://coinb.in/#fees, and in a few clicks you get the size including a recommended fee for a fast transaction. Note that most transactions don't need to be fast.

I guess it's a range. The size can be anywhere between those two however I'm not certain about this till now. Probably a senior member can confirm it.

A simple suggestion-
Do query on here or google. Read article, share here whatever you have learnt. Community will correct you. This thread can be an example of that.

Thanks for the additional information.
I really had no idea that inputs can actually affect one's transaction fee.

---

Now back you your calculation @RapTarX
we do see a +2 or -2 resulting into 470/456 bytes.

So which bytes do we consider? 470 or 456?
Or this is just a range where you can pick any value between 456 and 470 bytes and multiply with given rate which is currently 62sats/byte to get the total fees you have to pay?

---

Sorry for so many questions, I have been so reluctant in learning how to calculate these fees and this is an opportunity for me to know something