Wallet fee in sat/vbyte, blockchain in sat/byte question

[Oshosondy]

I am using a wallet that support bech32 addresses, I transfered bitcoin to a friend few days ago, though not yet confirmed till now, but I was surprised when I tracked the transaction on blockchain, the fee I saw was 2.93 sat/byte on blockchain, but I used 5 sat/vbytes on my wallet and the address is segwit bech32.

I know that using segwit will reduce the fee of about 42% if compared to raw transactions of legacy addresses. I just want to be sure, if miners are accepting 5 sat/byte, that means my transaction will also be accepted and confirmed or the mempool will still need to be reduced to 2.93 sat/byte before miners will accept it?

[1714978054]

1714978054

[1714978054]

1714978054

[1714978054]

1714978054

[ranochigo]

Blockchain.com uses raw size for the satoshis/byte and is thus inaccurate. You should be looking at the size/WU(Weight unit) for a better representation of the fees. Miners will usually consider fee rates in terms of vbyte and not it's size. Your transaction will stand a chance to get included once the 1vMB from tip of mempool falls to 5sat/vbyte and below.

[Oshosondy]

Blockchain.com uses raw size for the satoshis/byte and is thus inaccurate. You should be looking at the size/WU(Weight unit) for a better representation of the fees. Miners will usually consider fee rates in terms of vbyte and not it's size. Your transaction will stand a chance to get included once the 1vMB from tip of mempool falls to 5sat/vbyte and below.

I later used blockchair.com



I mean, if miners want to include it to a block, will they use /vbyte or /byte?

Edited: Okay, I have gotten you, that means my transaction will be confirmed right from 5 sat/vbyte.

[o_e_l_e_o]

I don't use blockchain.com for this reason. Its fee calculations have been incorrect ever since segwit was introduced and they still haven't bothered to fix it. Instead use blockchair.com and read the fee in sats/vbyte.

Sats per weight unit is the real measurement, but it is often easier to think in sats per vbyte, which is different by a factor of 4 in all cases, regardless of legacy or segwit. A fee of 1 sat per weight unit is the same as a fee of 4 sats per vbyte. Sats per byte is completely inaccurate since it takes no account of witness data.

Miners also work in sats per weight unit or vbyte, since this allows them to maximize their profits, but it also depends on what site you are using to look at the mempool. The main ones - jochen-hoenicke.de and mempool.space - use sats/vbyte like they should.

[ranochigo]

I mean, if miners want to include it to a block, will they use /vbyte or /byte?

The correct answer is that no one knows. Miners can choose to include certain transactions first for their own reasons and completely ignore the ordering of the transactions that they see. The way that they select the transactions might not even be strictly considering fees/size at all.

The logical answer is that if they want to maximize their transaction fees collected in a block, they would choose to include transactions based on fees/vbyte instead of strictly fees/size. Mempool sites like these represents the fees in terms of fees/vbyte.

[Oshosondy]

...

...

Thanks for the answers. Please one more question..

I have already known the difference very well now, but what if I transfer from legacy to legacy addreses which is a raw transaction, the sat/byte will be equal to sat/vbyte? Which will be the indication that no fee is reduced.

[ranochigo]

I have already known the difference very well now, but what if I transfer from legacy to legacy addreses which is a raw transaction, the sat/byte will be equal to sat/vbyte? Which will be the indication that no fee is reduced.

Yes, when you're spending from inputs associated with legacy address. There will not be any segwit discount as there's no witness in the transaction. The virtual bytes of the transaction will be equal to the raw bytes of the transaction in that case.