Topic: Difference between sat/byte, sat/WU and sat/vByte? (Read 178 times)
Making use of transaction size can not give accurate feerate while using nested segwit and native segwit addresses for transaction, it is only accurate when using legacy addresses, legacy address are not to be used because segwit can save up fee in a way lower fee will be used for transaction. So far segwit transactions make use of weight (vbyte) and not size (byte), the weight unit or vbyte should be used. So far mempool observers are estimating in vbytes, bitcoin transaction in feerate should be in sat/vbyte, although multiplying the feerate in sat/WU by 4 will still also give the result of sat/vbyte, but byte (size if the transaction) will give wrong feerate and fee estimation entirely for both nested and native segwit transactions.
Keep in mind that "sat/byte" unit is obsolete now and explorers and wallets must not use it to represent the fee rate that the transactions are paying since it would be both misleading and in any transaction with witness it will be the wrong value.
The simple answer is to use sat/vbyte in all situations and forget about the other two. This will let you accurately calculate the appropriate fee for your transaction.
The longer answer follows:
Transactions take up space, measured in bytes. This was accurate until segwit came along. Segwit transactions segregrate the witness data (hence the name seg-wit) in your transaction in to a different section. Although this data still takes up the same amount of raw bytes, it is calculated differently for the purposes of working out a fee. Non witness data takes up four weight units per byte, while witness data only takes up one weight unit per byte. The total size of your transaction in weight units is divided by 4 to give you the size in virtual bytes, or vbytes.
So a legacy transaction, for example, might be 200 raw bytes in size. It would have no witness data, and would therefore be 800 weight units and 200 virtual bytes.
A segwit transaction, for example, might also be 200 raw bytes in size, but 100 of those bytes are witness data and 100 are non witness data. It would therefore be 500 weight units and only 125 virtual bytes.
The longer answer follows:
Transactions take up space, measured in bytes. This was accurate until segwit came along. Segwit transactions segregrate the witness data (hence the name seg-wit) in your transaction in to a different section. Although this data still takes up the same amount of raw bytes, it is calculated differently for the purposes of working out a fee. Non witness data takes up four weight units per byte, while witness data only takes up one weight unit per byte. The total size of your transaction in weight units is divided by 4 to give you the size in virtual bytes, or vbytes.
So a legacy transaction, for example, might be 200 raw bytes in size. It would have no witness data, and would therefore be 800 weight units and 200 virtual bytes.
A segwit transaction, for example, might also be 200 raw bytes in size, but 100 of those bytes are witness data and 100 are non witness data. It would therefore be 500 weight units and only 125 virtual bytes.
sat/byte
This means that for every byte your transaction is, you'll pay the analogous satoshis.sat/WU
“WU” stands for “weight units”. After the SegWit activation in 2017, it has replaced bytesize as a measure of how much space transactions take when put into blocks. While a block can be up to 1MB, its weight is 4 million WU. Using SegWit reduces your transaction's WU size.sat/vByte
For legacy transactions: Byte = vByte. One virtual byte is equal with 4 WU. Essentially, sat/vByte tells you how many satoshis you'll pay for every 4 weight units of your transaction. Obviously, it'll be reduced if you're using SegWit. You should read this: Weight units
I recently sent a Bitcoin Segwit transcation and I noticed there are three different kinds of information regarding the fee high in terms of data size.
See image below:
Can someone explain what this is all about?
- sat/byte
- sat/WU
- sat/vByte
See image below:
Can someone explain what this is all about?
Jump to: