As mentioned in a previous article on ICO, calculating the fee for transactions is worth a standalone article. This discussion represents that deep technical dive into the mysterious calculations that support Bitcoin. To illustrate, let us charge right in and take conventional wire transfers as an example. As is common knowledge, banks often collect a small fee for transferring funds from one account to another. The same is true for Bitcoin transactions, except that there are individual miners instead of banks.
Miners are Bitcoin network users who make a profit by generating new blocks for the blockchain. Each block contains transactions that have been created and sent to the Bitcoin network but have not yet been included in the blockchain. In the Bitcoin world, there are no policies according to which transactions are attached to a block, so it is very important to set a strategic fee, otherwise the transaction may be inadvertently missed.
Miners can set the algorithms to select transactions to be included in the block. On first glance, it may appear that they simply include transactions with the biggest fee. In reality, it is a bit different.
First, let us calculate the socalled fee rate for each transaction according to the following formula:
Fee rate = Fee/Size.
To understand how transactions are included in a block, let us consider the following example. For instance, we have four transactions not yet included in any block.
Size  Fee rate  Fee  
TR1  200  10  2.000 
TR2  300  40  12.000 
TR3  400  20  8.000 
TR4  500  30  15.000 
Each transaction block is limited in size to 1000 KB (this alone is a topic for heated discussion). If we sort the transactions by size in an ascending order, the total fee obtained by the miner will be 22,000.
Given that, it seems logical to select transactions by fee size. Then, the miner would receive 27,000 by sorting the transactions by fee in a descending order.
However, analyzing more carefully, one can see that if TR4 and TR2 (transactions with the biggest fee) are included, 200KB of free space will remain in the block. This is not enough to include TR3, but enough to include TR1 (the transaction with the smallest fee). This will help to earn 2,000 more. As a result, the miner can get 29,000.
So a pattern has emerged, and most miners follow this principle: include transactions with the biggest fee first, and then fill in the space with small ones. Take advantage of a fascinating opportunity to track transactions, see how quickly they are included in blocks, and calculate the fee: https://bitcoinfees.earn.com/.
As is visible through the link above, transactions with fee = 0.0000000 are included within one hour or later– or sometimes they never are. It is up to the miner whether to include them or not, so there is a sizeable chance that the transaction will not be included at all. The same thing is true for transactions with an artificially low fee because it is unprofitable for miners to include it.
Now let us see how to calculate the fee correctly and what factors this depends on.
As mentioned in the previous article, a transaction that has been created cannot be rolled back because other transactions depend on it. A transaction has socalled inputs and outputs. The input is for other transactions that are confirmed, left unspent, and whose total exceeds the one requested by the user.
Therefore, to make a transfer, the user must select the transactions whose total is more than he wants to transfer.
Again, transactions are not summed up, and the value of each one will remain the same.
In general, a transaction follows this pattern:
The fee depends on the transaction size, or the number of bytes, not the amount of money, as in all areas of IT:
 10 bytes are required to the framework to save its system information;
 34 bytes per each outgoing address in the transaction;
 148 bytes per each incoming transaction.
Thus, the transaction size is calculated as follows:
transactionBytes = 148 * inputTransactionsCount + 34 * outputAddressesCount + 10
The entire algorithm has a complicated structure.
 Select all required unspent transactions whose total is more than the user wants to transfer.
 Calculate inputSum (sum up the products of the amount transferred in the transaction by the number of confirmations of this transaction).
 Calculate transaction size transactionBytes
 Calculate transactionPriority (inputSum divided by transactionBytes).
 Apply to the public node, call estimatesmartfee, and get the fee calculated using the algorithm embedded in Bitcoin API.
 Calculate the fee per 1000 bytes: feeRatePer1000Byte = 0.001, or, if the result of executing estimatesmartfee and estimatesmartfee[‘feerate’] > 0, then feeRatePer1000Byte = estimatesmartfee[‘feerate’]
 Calculate the fee using the formula: feeRatePer1000Byte* transactionBytes/1000
 minFee = 0.0001 if there is at least one input transaction less than 0.01, otherwise minFee = 0. If fee < minFee, then minFee if used as fee
It is worth mentioning that, in many sources, zero fees are processed separately if all the following conditions apply:
 transactionBytes < 10000, i.e. the transaction size is less than 10000 bytes
 transactionPriority > 0.576 This threshold was written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes
 All input transactions have the amount of transfer that exceeds or equals 0.01.
However, we did not use a zero fee for this type of transfer since the transaction might never be included into a block, as mentioned above.
The algorithm allows us to calculate the transaction fee sufficiently, shown here in this example. Let us assume that the user has Address 1 and needs to transfer 0.0023 BTC to Address 2. The incoming transactions are as follows:
BTC  Confirmations  
Transaction 1  0.01  6 
Transaction 2  0.003  12 
Transaction 3  0.0006  5 
Transaction 4  0.0021  10 
Transaction 5  0.0023  7 
The method of selecting the transactions is worthy of individual attention. At the beginning, it may seem that four options are possible:
 Take Transaction 1
 Take Transaction 2
 Take Transactions 3 and 4
 Take Transaction 5
If you have been attentive, you will see at once that the last option is not acceptable because the amount received is equal to the amount transferred, so the user will not have enough funds to pay the fee. To correct it, we can add Transaction 3 to Transaction 5, so we have the following options:
 Take Transaction 1
 Take Transaction 2
 Take Transactions 3 and 4
 Take Transactions 3 and 5
If we take the first option, only Transaction 1 will be input, since 0.01 BTC > 0.0023.
Still, since a transaction is a constant and cannot be divided, the remaining funds (NB!) must be returned to the user, otherwise they will go to the miner as a fee. To know exactly what amount should be transferred to whom, we should do the following:
 Calculate the fee.
 Determine whether the fee is paid from the remainder or from the amount transferred.
Let us be generous and transfer the fee from the remainder that should be returned to us.
Then, let us calculate the fee:
 Calculate inputSum = amount * confirmationsCount = 0.01*6 = 0.06.
 Calculate the transaction size. As there is one input transaction and two outputs (the transfer and returning the remainder), then transactionBytes = 148 * inputTransactionsCount + 34 * outputAddressesCount + 10 = 148*1 + 34*2 + 10 = 226
 Calculate the transaction priority: transactionPriority = 0.06/226 = 0.00026549
 Apply to the public node to call estimatesmartfee and get the fee calculated using the algorithm embedded in the Bitcoin API. The transaction is confirmed after six confirmations are received. In this case, estimatesmartfee = 0.00005044.
 Calculate the fee for 1000 bytes: feeRatePer1000Byte = estimatesmartfee = 0.00005044
 Calculate fee, fee = feeRatePer1000Byte * transactionBytes/1000 = 0.00005044*226/1000 = 0.0000114
 Since the input transaction is not less than 0.01, then fee = 0.0000114
Let us make the same calculation for all cases:
The transaction table is duplicated for your convenience:
BTC  Confirmations  
Transaction 1  0.01  6 
Transaction 2  0.003  12 
Transaction 3  0.0006  8 
Transaction 4  0.0021  10 
Transaction 5  0.0023  7 
Results:
1 
2 
3 and 4 
3 and 5 

inputSum  0.06  0.036  0.0258  0.0209 
transactionBytes  226  226  374  374 
transactionPriority  0.00026549  0.00015929  0.00006898  0.00005588 
feeRatePer1000Byte  0.00005044  0.00005044  0.00005044  0.00005044 
Fee (calc)  0.0000114  0.0000114  0.00001886  0.00001886 
minFee  0  0.0001  0.0001  0.0001 
Result  0.0000114  0.0001  0.0001  0.0001 
Even if we made it possible to transfer funds with a zero fee, it would not apply to any of the options, as the priorities are much less than the required value of 0.576. In this situation, the first option is preferable.
The input transaction will be Transaction 1, and at the output, we will transfer 0.0023BTC to Address 2 and the remainder of 0.01BTC – 0.0023BTC – 0.0000114BTC = 0.0076886BTC to Address 1. 0.0000114BTC is not transferred to anyone, so this is the fee.
If the fee were zero, then the difference between 0.01BTC and 0.0023BTC would be transferred to Address 1 as a remainder. It is also important to know that a remainder in the Bitcoin world is not the remaining amount from the old transaction but becomes a new unspent transaction with its own txid for the user at Address 1 after it is confirmed.
I hope this article has helped you to learn more about the mechanics of how the Bitcoin world works!