Thanks for everything.
I prefer its graphical presentation as well. I just like the BlockchainInfo website and figured they had something similar.
I'm looking at the 2nd graph "Pending Tx fee in btc" and the legend isn't making sense to me. Looking at the 2hr chart for today
at 13:12pm that peak says 1000+: 0.005btc
so the 1000 is sat/byte, if you sent then you would be paying .005btc or 500,000sats to send 1000sats
That sounds very high, I know its a lot lower only a minutes later but my tx fees on my mobile don't seem to match. They might
match with BlochchainInfo
You're reading it wrong... the "pending transaction fee in BTC" gives an indication of how much BTC
in total has been committed across ALL transactions with a fee
rate of 1000 (or higher) sats/byte.
It isn't an indication of how much you'll pay in total for your transaction... as that is defined by (fee
rate chosen * total size of
your transaction). The total size of your transaction being calculated based on number of inputs and number of outputs... inputs have different sizes (ie. native segwit < nested segwit < legacy) which is why "SegWit saves on fees"... smaller transaction size = smaller
total fee to be paid when you select the same fee
rate.
The most useful of those graphs are:
- "Unconfirmed Transaction Count" - The top chart. This gives a general indication of how many unconfirmed transactions are waiting... ie. how "busy" the network is currently... once this starts get up above 5-10,000... the fee rates start climbing.
- "Mempool size in MB" - The bottom chart. This shows the fee rates being paid by all the unconfirmed transactions. Remember, 1 block will take about ~1meg of transactions. So if you hover over the chart and see something like this:
We can see that there is almost 1 megabyte of transactions that pay a fee of 2 sats/byte (or higher)... so, if you use 1 sat/byte... chances are you're not going to get in the next block as there is already THREE blocks worth of transactions at the 1 sat/byte level... and even at 2 sats/byte, there is a good chance you might not get in the next block as that is almost already at 1 meg of transaction and other users could add in transactions with higher amounts.
If you want a quick confirmation, and the network isn't too busy... generally you can aim for the level that is around 0.5 or 0.6 MB... and you
should be ok... so in this example... if you pay around the 4 or 5 sats/byte fee rate, chances are good you'd get in the next block.
There are some caveats to that... like if 10000 people all send transactions in the next few minutes with higher fee rates, you'll probably end up missing out etc... but that's why the first chart can be important. If the network isn't too busy, like only 2-3000 transactions waiting, you might be OK... but if there are like 10000+... you really want to aim right up in fee rates around the 0.3 MB or less area (IF you need quick confirmation).
Here is one of my tx fees
_____
0.00000316 BTC
(1.404 sat/B - 0.351 sat/WU - 225 bytes)
_____
makes no sense, I can't even break it apart correctly, does it read...
"At a rate of 1.404 sats per byte the tx cost you 0.351 sats, because your tx was 225 bytes in size"
No... your transaction was 225 bytes... and you paid 1.404 sats/byte... so as above:
(fee rate * transaction size) = total fee
1.404 sats/byte * 225 bytes = 315.9 sats = 0.00000316 BTC
So you paid 0.00000316 BTC (or 316 sats) to send that transaction. NOTE: It would have cost you that regardless of the amount you sent... which is why sending very small amounts is not a very good idea, as the fee as a percentage of the total cost gets higher and higher, the smaller and smaller the amounts you're sending is!
ie. 0.00000316 BTC to send 0.00000600 BTC means you would have spent 0.00000916 and effectively ~33% is fees
... wheres 0.00000316 to send 0.00100000 BTC is 0.00100316 in total and 0.3% paid as a fee.
Also, the "sat/WU" metric has come about since the advent of SegWit... WU == "Weight Unit"... and is used because of the way SegWit transactions work. Instead, transactions now have a "Weight"... effectively, 1 byte = 4 WUs... and a block now has 4,000,000 WU's max size (1,000,000 bytes max block size * 4 = 4,000,000 WUs)
You can probably just ignore it all for now, as you're likely still dealing with older legacy private keys/addresses... so just stick to sats/byte and you shouldn't be too far off. Generally, a simple transaction that has 1 input and 2 outputs (payment + change) will be about the 225 bytes mark... so you can work your calculations off of that.
