Beginner's Guide to Transaction Fees

[Upgrade00]

The recent spike in the price of Bitcoin, and the halving event which took place earlier this month caused a spike in the transaction fees paid by senders. This has been a topic of discussion for quite a while, on how fees are calculated and ways to regulate transaction by paying low fees but still getting such transaction confirmed at an acceptable time.

What are transaction fees?
These are fees paid on each transaction being sent from one address to another on the Bitcoin network. The fees are paid to the miner who successfully adds the transaction to their confirmed block and the fees are also always paid by the sender of the bitcoins.
Some wallets allow spenders to select the fees they wish to pay to get a particular transaction confirmed based on the priority, basically, the higher the fees, the faster the transaction and vice versa. However there are other variables that affects which transaction would get picked first by miners. To fully understand transaction fees one has been able to to how transactions are effected:

When bitcoins are sent from one address to another, the private key of the sending address is used to sign the transaction, it is then sent to the mempool where it is verified by nodes, who confirm that such inputs are in the sending address, the transaction is then moved to miners who add it to their block based on priority. When a block is confirmed, it is verified by nodes and the transaction is complete and irreversible.

Source

Each Bitcoin is represented on the public ledger or blockchain, this serves as a record of all transactions [arranged chronologically] that has been made over time. Bitcoin supply increases whenever miners successfully confirm a block, because they receive a reward or coinbase. This transaction has no source and can not be dated back, they basically come out of thin air, any subsequent transaction has to have an input and an output
Inputs are bitcoins received into an address from a spender and outputs are bitcoins sent to a receiving address.

How are transaction fees calculated?

The amount a spender would pay to get an output confirmed depends on two variables;

• The feerate
• The transaction size

THE FEERATE: this is the amount miners charge for each byte of space in their block.
Each transaction takes up space in a block based on it's size, hence there is a limit to the amount of transactions that can be added, also only whole transactions can be added. Hence, miners try to maximize the space available by taking the most profitable transactions.

- Each block has a maximum space (used to be less than or equal to 1 mega byte but due to the implementation of segwit transaction now has a maximum size of 4mb)
- Transactions which are calculated in bytes are added to it until it gets filled.
- Feerates are calculated in Satoshi per byte (sat/byte)
- The amount of Satoshi that would be paid on every byte of space in a block is dependent on the interaction of demand and supply on the Bitcoin network. If there is a higher activity on the network, due maybe to a rise in market price, this could create a lag and spenders would increase their transaction fees to get it confirmed faster, this increases the average feerate on each transaction added to a block.

TRANSACTION SIZE: as I mentioned earlier, blocks contain 1mb of space and transactions are added based on their fees and size. This means that every transaction has a size. Transaction size is simply the number of inputs and outputs involved in it.
If I wish to send 0.5BTC which I received from two separate transactions (0.2/0.3) this means I have 2 inputs involved in the transaction. This transaction is then sent to the mempool where nodes verify the transactions, this is a way of confirming that I truly own those inputs in my address.

Outputs is the outgoing bitcoins, typically when sending to one address, you should have 1 output, but it's actually 2, the second one is the change address which received the unspent inputs.
Take for example, I have 3 inputs 0.2BTC, 0.4BTC and 0.2BTC totalling to 0.8BTC and I wish to send 0.7BTC, all 3 inputs would need to be compiled but not all will be spent, the unspent inputs gets sent back to me through a change address
The larger the number of inputs and outputs involved in a transaction the bigger it's size. Due to the different types of of addresses the size of a transaction is more complicated to calculate manually. You can use this link to find an estimate of your transaction's size - https://coinb.in/#fees
To determine the transaction fee, you multiply the transaction size by the current feerate. The amount of bitcoins being sent does not influence it.
*Scipt complexity also influences transaction size.

How to minimize transaction fees?

With the current spike in fees, many would be interested in ways to reduce the fees. To reduce the fees one or both of the variable involve has to be reduced.
The standard feerate is determined by the level of activity in the network, so;
• timing your transactions can result in significantly lower fees. During a FOMO period, lots of investors are looking to get in and more traders are active, this is probably not a good time to transact, if it's not time sensitive, when the resulting activity cools, the feerate would also reduce, leading to lower transaction fees.

Reducing the transaction size would also reduce the fees incurred, this can be done through a couple of ways:
• Reducing the number of inputs: the higher the number of inputs involved in a transaction, the higher the size, so to reduce the size, less inputs should be spent.
If I receive 0.4BTC and spend that in a single transaction, the size would be smaller than a 0.2BTC transaction comprising two separate inputs (0.1,0.1BTC).

• Batching receptients : add multiple receiving addresses to a single transaction saves more cost than sending them in separate transactions.

• Consolidateling inputs and outputs: when an entire input involved in a transaction is not spent, this creates the need for a change address to receive the unspent coins. Spending the exact amount of an input would eliminate the need for a change address hence reducing the amount of outputs and also the transaction size.

Note that, inputs weigh more in a transaction and reducing them should be prioritized when looking to reduce fees.

•Using a Segwit address:  for a detailed explanation on how segwit functions, check out this thread - https://bitcointalk.org/index.php?topic=5198733.msg52985661#msg52985661
Higher transaction fees and lower size means a transaction is likely to get picked by a miner and confirmed much faster. If you're not in a particular hurry, you can select a minimal fee and wait for it to get confirmed. If a fee is too low a transaction can remain pending till it is dropped from the mempool (this takes ~ 72hours). If this happens the transaction is cancelled and the inputs are returned to the wallet.
I have a question here: if a transaction gets cancelled, is it returned through a change address?
If your transaction remains in the mempool for a long time and you wish to have it confirmed, you can do this through;
• Replace-by-fee
• Child-Pays-For-Parent
Another protocol aimed at making transactions more efficient, but not directly linked to the Bitcoin network is:
• Lightening Network
Other links:
•Bitcoin fee calculator and estimator

[Pffrt]

There's a thread made by another member long ago- https://bitcointalk.org/index.php?topic=5153031.0 although yours one is more detailed and include more info for beginners.

•Using a Segwit address: segwit addresses are designed to reduce the size of transactions created, thus reducing the fees involved in spending inputs. Some would say that segwit increases the block size, I cannot however confirm this, with contributions in the comments we may be able to.

This is a misconception, most of the users are in this misconception. You can check the explanation here- https://bitcointalk.org/index.php?topic=5198733.msg52985661#msg52985661

[masulum]

I want to add about Replace By Fee (RBF) feature since you mentioned it on your thread. Just to make sure for every beginner (using Bitcoin) to know if not all wallet supported this feature. Some of wallet already supported RBF (you can search for other)
1. Bitcoin core
2. Electrum  (PC)
3. Samourai Wallet

Since i'm only using Electrum, If you want to know if RBF feature are enabled on this wallet, you can check this menu, Tools > Preference > Fees > Mark Use Replace-By-Fee




This is another good topic related to transaction fee by @1miau Make sure to avoid wasting BTC for too high fees – step by step guide (Electrum)

Good thread @OP

[Pffrt]

2. Electrum  (PC)

RBF method is supported in Electrum mobile wallet too. I have done that several times. You have to opt in RBF before releasing a tx, otherwise, you will not be able to increase the fee later.

[o_e_l_e_o]

- Each block has a maximum space (less than or equal to 1 mega byte)
- Transactions which are calculated in bytes are added to it until it gets filled.
- Feerates are calculated in Satoshi per byte (sat/byte)

This used to be accurate, before SegWit was activated. Blocks now have a maximum size of 4 million weight units, which is equal to 1 million virtual bytes, giving them an effective maximum size of 4 MB. Transaction size and fee rates are now calculated in weight units or more commonly in vbytes, and not in simple bytes. Although for transactions which only include legacy inputs and outputs the size in vbytes is the same as the size in bytes, this is not the case for transaction which include any nested or native segwit inputs or outputs, which will be smaller in vbytes than they are in bytes.

Code:

(148 × no of inputs) + (34 × no. of outputs) + 10bytes ± in = transaction size in bytes

As above, this is only accurate for transactions which only contain legacy inputs and outputs.

Some would say that segwit increases the block size, I cannot however confirm this, with contributions in the comments we may be able to.

See my explanation above.

If a fee is too low a transaction can remain pending till it is dropped from the mempool (this takes ~ 72hours).

It used to be 72 hours, but as of Bitcoin Core 0.14.0, the default mempool expiry time has been two weeks (although individual nodes are obviously free to change this).

[Upgrade00]

See my explanation above.

Thank you for the corrections, I needed some clarifications as to how segwit influenced the network and I was getting conflicting details from various sites.
I'll add some of the information to the OP now

This is a misconception, most of the users are in this misconception. You can check the explanation here- https://bitcointalk.org/index.php?topic=5198733.msg52985661#msg52985661

Noted, I'll replace that text with a link to that reply, so other users can get the information first hand.

[o_e_l_e_o]

No problem, happy to help.

The best place to read about SegWit and know that you are not getting incorrect information is BIP141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), but this assumes a certain level of technical knowledge. Another good less technical resource is https://bitcoincore.org/en/2016/01/26/segwit-benefits/.

I have a question here: if a transaction gets cancelled, is it returned through a change address?

No. First of all, the transaction is never really "cancelled". It simply drops from each node's mempool after a set amount of time. The transaction itself is still valid, and could be rebroadcast by anyone at any time and re-enter the mempool, and potentially be confirmed (perhaps when the fees are lower). The only way a transaction can be truly "cancelled" is if the inputs in that transaction are spent in another transaction first, and so the original transaction becomes invalid.

When a transaction drops from the mempool, it's like it never existed in the first place. The coins do not move from their original addresses, and there is no change.

[khaled0111]

• timing your transactions can result in significantly lower fees. During a FOMO period, lots of investors are looking to get in and more traders are active, this is probably not a good time to transact, if it's not time sensitive, when the resulting activity cools, the feerate would also reduce, leading to lower transaction fees.

True, choosing the right time to broadcast your transaction can help you save on fees.
According to this analysis made by tranthidung, fees are usually lower during weekends.

• Consolidateling inputs and outputs: when an entire input involved in a transaction is not spent, this creates the need for a change address to receive the unspent coins. Spending the exact amount of an input would eliminate the need for a change address hence reducing the amount of outputs and also the transaction size.

Well, this is not exactly consolidating. It's more like coin control which you explained in a previous point (Reducing the number of inputs).
Consolidating means gathering different UTXOs in a single transaction and sending them to a new address. You can read more about it here:
[MAY 2020] Fees are low, use this opportunity to Consolidate your small inputs!

[Upgrade00]

Well, this is not exactly consolidating. It's more like coin control which you explained in a previous point (Reducing the number of inputs).
Consolidating means gathering different UTXOs in a single transaction and sending them to a new address. You can read more about it

The suggestion I was passing on was a way of reducing number of outputs rather than inputs. I could replace consolidating with matching inputs and outputs, to prevent the need for a change address which would increase the number of outputs which goes into a transaction.

If I received 0.056BTC in a single UTXO and I wanted to spend 0.5BTC, the remaining 0.006BTC will get returned through a change address, increasing the number of outputs. If however I spent the entire 0.056BTC, there will be no need for an extra output, thus reducing the transaction size.

[khaled0111]

If I received 0.056BTC in a single UTXO and I wanted to spend 0.5BTC, the remaining 0.006BTC will get returned through a change address, increasing the number of outputs. If however I spent the entire 0.056BTC, there will be no need for an extra output, thus reducing the transaction size.

I am not sure if I understood you correctly, but in real life you will be sending these coins to someone else not to yourself. Are you suggesting to not request the change back and to pay more than you should just to reduce the transaction size?
Unless the change amount will be smaller than what you will pay as extra fee to add a change address then what you suggested doesn't make sense and you will lose more than what you would save.

[Upgrade00]

I am not sure if I understood you correctly, but in real life you will be sending these coins to someone else not to yourself. Are you suggesting to not request the change back and to pay more than you should just to reduce the transaction size?

You make a valid point and this suggestion can only be used in limited situations; such as when you need to make two different transactions to transactions to someone over a period of time but rather merge them into one so as to spend the exact amount in a single UTXO. It could also be useful when sending to a close relative. Newbies can keep it in mind as a workaround should a situation arise where it can be implemented without incurring extra cost.

[Upgrade00]

Check out this thread for how to save fees now, to prevent paying excess at a time when the network gets clogged up; [July 2020]Fees are low, use this opportunity to Consolidate your small inputs!

[Upgrade00]

Bump - periods of low fees is the ideal time to save up on fees in preparation for when the mempool would get clogged again.

[Lordhermes]

I want to add about Replace By Fee (RBF) feature since you mentioned it on your thread. Just to make sure for every beginner (using Bitcoin) to know if not all wallet supported this feature. Some of wallet already supported RBF (you can search for other)
1. Bitcoin core
2. Electrum  (PC)
3. Samourai Wallet

In addition to the ones listed above, I would have added more ones to listed above that support RBF
[1]. Bitcoin armory
[2]. MultiBit HD