Understanding Bitcoin Fees: Their Purpose, Functionality, and Tips to Save Satoshis

So what's the deal with Bitcoin transaction fees and how do they actually work? Basically, a Bitcoin transaction fee is a tiny amount you throw in there to motivate miners to pick up your transaction and add it to a block. There’s no set fee. You pay whatever you think will get your transaction confirmed in a timely manner. If the network is super busy and everyone’s sending BTC, you're gonna have to fork out more cash or your transaction might just chill unconfirmed for ages. It's important to realize that you’re not paying a specific person or company. You're sorta tipping the miner to prioritize your transaction. A common misconception is that the fee is based on the amount of BTC you send. That’s wrong. You could send something for just a dollar and pay a higher fee than someone sending a grand. The fee hinges on how much data your transaction takes up. If your wallet uses a lot of inputs, that makes the transaction bigger, and bigger transactions mean higher fees to fit into a block. So that fee is just your way of saying, "Hey miner, could you prioritize mine?" If your tip is too low during peak times, then you’re gonna have to wait. Some folks feel like they’re paying random amounts just to move their own cash around. Other people find the fees totally unfair, especially when a small transaction ends up costing more than they thought. And those wild moments when a transaction is stuck unconfirmed for hours or even days? Yeah, I’ve been through that too. I wanted to break this down so others can grasp what Bitcoin fees are all about, why they fluctuate, how they get calculated, and a bit more.

You can decrease the transaction fee by using bech32 addresses (segwit version 0) instead of legacy addresses, but that's not due to segwit addresses decreasing the transaction size. If you use segwit addresses, your transaction would include some witness data that is counted as 1/4 of non-witness data and that's why you pay lower fees when using segwit addresses. Taproot addresses (segwit version 1) don't necessarily decrease the transaction fee and they can even make you pay higher fees. Each block can include up to 1 vMB of transactions and the maximum number of transactions that can be in a block depends on the virtual size of the transactions.

SegWit can be native or nested, it's important you make that difference. Native segwit (bc1q..) transactions are way lower than nested segwit transaction(3.....) but generally they have lower transaction vbytes than legacy addresses(1.....). There isn't much difference between Taproot(bc1p..) and native segwit(bc1q..) if you are sending a 1 input and 1 output transaction. The only place Taproot is more useful is if you are spending more inputs, like consolidating plenty of inputs; then Taproot gives you an upper advantage. However, sending to many outputs, native SegWit saves you more on the transaction fees. I'm making an emphasis on the bolded and not the dust. If you have more inputs, it doesn't mean you will spend more, provided that the mempool is less congested. Taproot addresses can help you spend plenty of inputs; this is only possible if all of your inputs are received on Taproot addresses, but not helpful on dust amounts, only when you have many inputs you want to consolidate. If you don't own the receiving wallet private keys or have any change private key from your transaction, CPFP will become useless if your transaction remains unconfirmed in the mempool. To avoid your transaction getting stuck forever in the mempool, it is wise to use a wallet that supports RBF so you don't have to do CPFP, wallets like Electrum by default make your transaction flagged as RBF so you can always bump the fee anytime there is fluctuation in the mempool.

And for people who use custodial service/wallet, it's worth to mention that those service take profit by charging TX fee higher than required to get a TX confirmed on Bitcoin network. This isn't accurate. Actual block size limit is 4 MWU (also called 4 million weight unit) unit or 1 vMB which refer to same thing. Your 1 to 1.5MB estimation is based on how much TX data included in a block is categorized as witness data or not.

4 kWU would only be 4,000 WU, so you're off by factor 1,000 (but you write correctly 4 million WU). You may want to correct it to avoid inconsistancy. A chart of the average number of transactions per block can be inspected e.g. here: https://ycharts.com/indicators/bitcoin_average_transactions_per_block A chart of the average Bitcoin block size can be found e.g. here: https://ycharts.com/indicators/bitcoin_average_block_size

I think OP statement of having little inputs might be the little amounts on change addresses which were as a result of left overs from spent transactions and since each UTXO is treated as an input and each will increase the transaction fee when included as part of the transaction except if they were Recieved on taproot addresses as you stated. Easy thing to do if they are on another address is to simply freeze this UTXO so they are not included as part of any transactions Most of the time CPFP isn’t even that good idea because it actually requires more transaction fee since you need to double the transaction fee of both the first parent transaction, the second parent transaction (the child transaction fee to the first parent transaction) so that both can confirm faster and get the last transaction fee confirmed, it is not even advisable on transactions having larger inputs again. Also aside electrum been Full RBF, most nodes now have even be configured to be full RBF too.

Nodes doesn't really configure transactions as RBF, there are some custom nodes that replace a transaction when they see a new transactions that has higher fee than the initial transaction but don't change transactions without RBF to RBF this is because RBF are flagged within the transaction, there is a data included by the sender to signal the transaction to be replace by high fees if it doesn't get confirmed from the mempool.. The sender must opt-in this feature when sending the transaction else other nodes will see it as not enabled RBF except for few some nodes that allow transactions to be replace but not really fully RBF in real sense.

There are actually nodes that do configure as full RBF. The setting was actually opt-in RBF or full RBF and this gives every node the ability to enabled their configuration as Full RBF and if it’s enabled for a node all transactions in the nodes mempool will be treated as Full RBF but this doesn’t makes the transaction it self as Full RBF because it can ever be full RBF if the sender makes it so, in the other nodes which still have opt-in RBF it will not be flagged as RBF. So technically Nodes can configure as Full RBF enabled but can only treat the transaction in their nodes as such but outside the node it is treated base on the node configuration except if it was enabled by the sender

And that brings me back to this:   It doesn't cost anything to enable RBF on your transaction; mempool rarely gets full these days. 1~3 sats and you will get your transaction included in the next block. If there is a spike in the mempool and you don't have RBF enabled and there is no change in your transaction or you don't control the receiving address, you will have to wait until the mempool clears some transactions. It is worth doing it rather than going looking for a peer node that has RBF enabled that can accept your transaction, and not just that, you need to run a Bitcoin node to be able to connect with the nodes like Peter Todd's nodes. These nodes accept transactions that are not RBF, but you need your own node to be able to connect. If you have an SPV wallet like Electrum, Coins.ib might do the trick, but you will be broadcasting with "hope" that it gets propagated to a peer node that accepts your transaction with a new high fee, but all for what? These are possible, but in my opinion, the stress isn't worth it when you can simply do it from the beginning by having RBF enabled.