Please, never mind my questions.

[Oshosondy]

It is about fee paying using legacy, compatibility and segwit addresses.

Legacy- addresses that start with 1
Compatible- addresses that start with 3
Segwit- addresses that start with bc1

Which ones will the low fees, by using low, medium and high fee.

1. Sending from legacy to legacy addresses? I know this is the highest though
2. Sending from compatible to compatible addresses? I know this is medium though
3. Sending from segwit to sedwit? I know this is the lowest though.

But what about
4. Sending from segwit to legacy?
5. Sending from legacy to segwit?

The explanation from 4 and 5 will let me relate it to all other transactions to know how it works.

[ranochigo]

4. Sending from segwit to legacy?

Slightly larger than Segwit to Segwit by about 3 bytes. When comparing legacy and Bech32 addresses in the scriptpubkey, you'll notice the difference.

ScriptPubkey of bech32 output: OP_0 ....
ScriptPubkey of P2PKH (legacy): OP_Dup OP_Hash160 ... OP_Equalverify OP_Checksig

5. Sending from legacy to segwit?

Same logic. Smaller than legacy to legacy by 3 bytes.

[Oshosondy]

...

Thank you ranochigo, calculating bitcoin fee has been a problem for me ever since the beginning that I was learning about it. Please is there any book or guild that can be used to calculate bitcoin fee in a way I will be able to know how to calculate bitcoin fee even for inputs and outputs and also for sending from one bitcoin addresses to another.

[NotATether]

...

Thank you ranochigo, calculating bitcoin fee has been a problem for me ever since the beginning that I was learning about it. Please is there any book or guild that can be used to calculate bitcoin fee in a way I will be able to know how to calculate bitcoin fee even for inputs and outputs and also for sending from one bitcoin addresses to another.

If you mean calculating the total fee, as opposed to the fee rate, it is additionally dependent on the size of your transaction. So using a large custom script in the transaction or spending a lot of inputs at once will increase the total fee dramatically.

As for figuring out the fee rate, they are notoriously difficult to get right and you're better off not trying, and work in terms of confirmations within the next "N" blocks or in terms of megabytes from the tip instead. The latter metric is how deep in the mempool (a data structure full of transactions) your transaction will reside. Higher up transactions get processed first, whether by paying a high fee or otherwise.

[HCP]

As ranochigo noted, the differences based on the type of output you're creating a very minimal... almost to the point of being inconsequential in the grand scheme of things (unless you're paying fee rates in the 1000's of sats/byte )

The general rule of thumb is that (when considering the size of inputs):

native segwit < nested segwit < legacy


Of course, this only applies when the number of inputs being used to construct the transaction is the same... That is to say, the fact you're using native segwit inputs won't really matter if you're using 100 inputs

Please is there any book or guild that can be used to calculate bitcoin fee in a way I will be able to know how to calculate bitcoin fee even for inputs and outputs and also for sending from one bitcoin addresses to another.

This tool is pretty simple: https://btc.network/estimate

You can set inputs/outputs and whether or not you're using SegWit... but it seems to be "ignoring" the slight differences in output type, so it doesn't show the differences for sending from one type to the other... which, as stated, are really quite insignificant. 3 bytes per output? for a standard transaction that's like ~2% on a 1 input/2 output SegWit transaction... and ~1% on a 1 in/2out legacy transaction.

It also, has some explanation on how it is calculating the transaction sizes... and the assumptions it is making when doing so.