For this 25.5 sats/byte transaction, why is the listed fee 14.395 sats/byte?

I made a 372 byte transaction the other day back when fees were a staggering 53.5 satoshis per byte. I considered that very excessive and wanting my transaction to be confirmed within 6 hours, I lowered it to 25.5 sats/byte instead (as long as the inputs are large enough I don't mind spending up to $1 in fees if it makes them happen in a reasonable time).

But if you view this transaction on the blockchain, https://www.blockchain.com/btc/tx/1b39e33531585a5804e8f14425985a1836d386c5005a8358a5f0c439280b2fe4, it lists a fee of 14.395 sat/byte and 6.398 sat/WU. The amount I payed in fees is the same as listed so why does it appear that the transaction fee became less? And what is the sat/WU figure in the listing?

Its just blockchain.com's UI error.

Segwit transactions are calculated differently from normal legacy transactions. The vbytes for segwit transaction is lesser. Blockchain.com took your sat/bytes instead of sat/vbytes. No worries though, miners looks at vbytes and not bytes.

WU is weight units.

Quote from: ranochigo on July 30, 2020, 10:17:31 AM

I seem to get it now that I looked up weight units in the Bitcoin wiki, apparently I can calculate the bytes tx fee from it and whatever blockchain.com showed me was the sats/vbytes. Since miners only look at the sat/vbytes value, how should I choose a suitable tx fee for segwit addresses? For this transaction I used https://jochen-hoenicke.de/queue/#0,1w to choose a suitable fee but that lists fees in sat/bytes and since vbytes is less than bytes I wonder if this means these transactions will be included slower than legacy addresses?

Quote from: NotATether on July 30, 2020, 10:28:46 AM

Blockchain.com showed you sat/bytes. Your wallet was using sat/vbytes. Try to avoid blockchain.com and switch to a better block explorer.

Jochen's estimator actually displays the fees in sat/vbytes when you look closely at the explanation at the bottom.

The transaction you linked to is 372 bytes. 155 bytes of that is non-witness data, and 217 bytes is witness data.

Because your transaction is SegWit, the non-witness data each takes up 4 weight units, but the witness data only takes up 1 weight unit. This means your transaction has a weight of (155*4) + 217 = 837 weight units.

837 weight units, divided by 4, means your transaction has a virtual size of 209.25 virtual bytes. This is the number that is used when calculating fees.

Quote from: NotATether on July 30, 2020, 10:28:46 AM

Since miners only look at the sat/vbytes value, how should I choose a suitable tx fee for segwit addresses?

Which wallet are you using? Most good wallets will work out the virtual size and use it in the fee calculation automatically.

Quote from: o_e_l_e_o on July 30, 2020, 11:20:02 AM

Quote from: NotATether on July 30, 2020, 10:28:46 AM

Since miners only look at the sat/vbytes value, how should I choose a suitable tx fee for segwit addresses?

Which wallet are you using? Most good wallets will work out the virtual size and use it in the fee calculation automatically.

I used electrum to make that transaction. I kind of wish it let you choose a vbytes fee instead of a bytes fee if it detects a segwit wallet open.

The fee you select in Electrum is in sats/vbyte, although it doesn't say that. In the case of the transaction you linked in your first post, the fee you selected of 25.5 sats/vbyte is what you paid. The incorrect fee of 14.395 is because the explorer you looked it up on is inaccurate. If you look it up on blockchair or blockstream, you will see the 25.5 fee displayed accurately.

Quote from: NotATether on July 30, 2020, 04:08:27 PM

I used electrum to make that transaction. I kind of wish it let you choose a vbytes fee instead of a bytes fee if it detects a segwit wallet open.

As others have stated... it is a sats/vbyte fee used in Electrum... It is simply a UI decision made by the devs to get the terminology the same across all transactions.

It can be very confusing because when some places say "sats/byte" that do actually mean sats/byte... as opposed to sats/vbyte Undecided

I would definitely recommend that you stop using blockchain.com and switch to one of the other explorers like:
btc.com
blockchair.com
or
blockstream.info

That all do a much better job of showing the difference between bytes/vbytes and the matching fee rates

Quote from: NotATether on July 30, 2020, 10:28:46 AM

For this transaction I used https://jochen-hoenicke.de/queue/#0,1w to choose a suitable fee but that lists fees in sat/bytes

For the record, "johoe's bitcoin mempool size chart" also base the transactions in vbytes so those MB are actually "(virtual) MB" and sat/B are "sat/vB".
This is written below the page:

Quote from: https://jochen-hoenicke.de/queue/

The transactions are colored by the amount of fee they pay per (virtual) byte.

Quote from: NotATether

and since vbytes is less than bytes I wonder if this means these transactions will be included slower than legacy addresses?

Lower virtual size wont matter with the prioritization, miners will use the "fee rate" (n sat/vByte) and lower vbytes means lower total fees to pay.
For legacy, the virtual size and size will be the same since all of its data are all non-Witness.

You might be missing the point of "n sat/vByte", it's as simple as this, example:
3sat/vB of a SegWit transaction with 134 vBytes size. Just multiply it and you'll get the total fee of your transaction = 402 satoshi.
2sat/B of a Legacy transaction with 235 Bytes size = 470 satoshi.
In this case SegWit transaction will be prioritized over the Legacy transaction even though it has lower virtual size and lower total fee since it's paying a higher fee rate.