How can I know the bytes of a transaction?

[BlackHatCoiner]

Before I make any transaction, how can I know the size of it? So I can calculate the exact amount of satoshis that will be sent to the miner.

(Not sure if the x satoshis per byte happens only on electrum)

[TryNinja]

On Electrum, you can click "Preview" (versions < 4.0) or "Pay -> Advanced" (versions > 4.0) before sending a transaction to check the transactions details, such as size. Electrum already shows you (and lets you change) how much you are paying in satoshis and sat/byte. If you just want to calculate how much a supposed transaction would weight, you can use http://coinb.in/#fees to play around with it.

(Not sure if the x satoshis per byte happens only on electrum)

X sat/bytes (or kb/vB) are a norm. That's how fees are calculated (based on the weight of the transaction).

[o_e_l_e_o]

(Not sure if the x satoshis per byte happens only on electrum)

Sats per byte is a commonly used unit for fees, but it is inaccurate for all transactions except transactions only containing legacy data. Instead, we should now use sats per virtual byte.

Since SegWit, all transactions are now calculated based on weight units rather than bytes. Legacy data takes up 4 weight units per byte, but witness data in SegWit transactions only takes up 1 weight unit per byte. There are 4 weight units in a virtual byte.

What this means in practice is that if you make a legacy transaction, its size in virtual bytes will be the same as its size in bytes, and so your fee will be accurate.
If you make a transaction which contains SegWit data, its size in virtual bytes will be smaller than its size in bytes, and if you pay a fee based on sats per byte, you will end up over paying.

Although Electrum says sats per byte, it is actually correctly showing sats per vbyte. Not all wallets or block explorers are accurate, however.

[BlackHatCoiner]

(Not sure if the x satoshis per byte happens only on electrum)

Sats per byte is a commonly used unit for fees, but it is inaccurate for all transactions except transactions only containing legacy data. Instead, we should now use sats per virtual byte.

Since SegWit, all transactions are now calculated based on weight units rather than bytes. Legacy data takes up 4 weight units per byte, but witness data in SegWit transactions only takes up 1 weight unit per byte. There are 4 weight units in a virtual byte.

What this means in practice is that if you make a legacy transaction, its size in virtual bytes will be the same as its size in bytes, and so your fee will be accurate.
If you make a transaction which contains SegWit data, its size in virtual bytes will be smaller than its size in bytes, and if you pay a fee based on sats per byte, you will end up over paying.

Although Electrum says sats per byte, it is actually correctly showing sats per vbyte. Not all wallets or block explorers are accurate, however.

If I understood correctly, if you use SegWit, you pay a different amount of fee, instead with a Legacy?

[bitmover]

you can play around this website as well so you can see the size of the transaction:
https://www.buybitcoinworldwide.com/fee-calculator/

You can see how much it is important to have consolidated inputs (more information here in this guide by LoyceV Fees are low, use this opportunity to Consolidate your small inputs! and use segwit addresses. The less inputs/outputs you have, smaller is the transaction.

[o_e_l_e_o]

If I understood correctly, if you use SegWit, you pay a different amount of fee, instead with a Legacy?

SegWit transactions take up fewer virtual bytes than legacy transactions. This means you can spend a smaller overall fee to get the same fee rate than with a legacy transactions.

For example, lets say a legacy transaction is 800 bytes. It would also be 800 virtual bytes, and so to pay a rate of 10 sats/vbyte would cost you 8000 sats.
The same transaction using SegWit inputs, although also 800 bytes, might only be 500 virtual bytes, and so 10 sats/vbyte would only cost 5000 sats.

[BlackHatCoiner]

If I understood correctly, if you use SegWit, you pay a different amount of fee, instead with a Legacy?

SegWit transactions take up fewer virtual bytes than legacy transactions. This means you can spend a smaller overall fee to get the same fee rate than with a legacy transactions.

For example, lets say a legacy transaction is 800 bytes. It would also be 800 virtual bytes, and so to pay a rate of 10 sats/vbyte would cost you 8000 sats.
The same transaction using SegWit inputs, although also 800 bytes, might only be 500 virtual bytes, and so 10 sats/vbyte would only cost 5000 sats.

Why does bytes matter? The miner will look at the 8000 sats instead of the 5000 ones.
Miners look at the sum of sats/byte, and not the sats/byte by itself, right?

[HCP]

Why does bytes matter? The miner will look at the 8000 sats instead of the 5000 ones.
Miners look at the sum of sats/byte, and not the sats/byte by itself, right?

It matters because while higher fee rate transactions is how (in general) you maximise the total amount of fees that you can get from a block... you also have to remember that the block size is limited!

So, by taking the transaction that is only 500 virtual bytes (instead of the 800 vbyte one), a miner still has another 300 virtual bytes to use in the block... so they might be able to find another transaction, maybe one that is 300 vbytes and paying 15 sats/vbyte, or 4500 sats... so they'd end up with 9500 sats in total, instead of only 8000 sats if the take the 800 vbyte transaction.

It really is a bit of a juggling act that miners need to do when they're trying to fill blocks and maximise their returns.

[pooya87]

It really is a bit of a juggling act that miners need to do when they're trying to fill blocks and maximise their returns.

it is not really a juggling act though. it is just as simple as it has ever been even before SegWit but with a tiny change that they compute fees in terms of "virtual bytes" instead of "bytes". then it is a matter of comparing the rates just like before. if one transaction is paying X and another Y and X > Y then the transaction paying X is preferred.
looking at this from outside seems complicated because people think in terms of raw bytes.

[nc50lc]

Miners look at the sum of sats/byte, and not the sats/byte by itself, right?

Forget the intricate stuffs and manual computations, if your wallet/client supports SegWit and showing sat/vByte or sat/B, then use that.
Miners will pick the higher sat/vByte transaction (fee rate) rather than the total paid fees.

[HCP]

if one transaction is paying X and another Y and X > Y then the transaction paying X is preferred.

Miners will pick the higher sat/vByte transaction (fee rate) rather than the total paid fees.

Not in all instances... there are instances where a lower fee rate would be preferred... but that's only in a few "edge" cases when you're attempting to fill the very end of a block and there are a limited number of transactions left to choose from...

ie. if you have 1000 bytes left... and you have a 900 byte transaction paying 1 sat/bye... and a 101 byte transaction that pays 5 sats/byte... you can't take both, so obviously, you'd take the 900 byte transaction

The likelihood of this actually occurring are fairly small... but it is still possible... and then you get into the mechanics of monitoring new transactions being added and rejuggling the transactions you want to put into your block etc... like I said... it's a juggling act


But yes, in general, highest fee rate will 999/1000 times win

[pooya87]

Not in all instances... there are instances where a lower fee rate would be preferred... but that's only in a few "edge" cases when you're attempting to fill the very end of a block and there are a limited number of transactions left to choose from...

ie. if you have 1000 bytes left... and you have a 900 byte transaction paying 1 sat/bye... and a 101 byte transaction that pays 5 sats/byte... you can't take both, so obviously, you'd take the 900 byte transaction

The likelihood of this actually occurring are fairly small... but it is still possible... and then you get into the mechanics of monitoring new transactions being added and rejuggling the transactions you want to put into your block etc... like I said... it's a juggling act

true, but this falls under the implementation details that some miners (maybe the smaller mining pools) don't even bother with that is why we see  blocks that may still have some tiny room left for another transaction to be placed among their transaction list.

[o_e_l_e_o]

Why does bytes matter? The miner will look at the 8000 sats instead of the 5000 ones.
Miners look at the sum of sats/byte, and not the sats/byte by itself, right?

Here's an analogy which might help you to understand a bit better.

Let's say you are a delivery driver. Each morning you go to a warehouse with your truck, and there are a bunch of different jobs you can choose from. Today, you see the following jobs posted:

• Deliver a table and chairs for $50
• Deliver a TV for $30
• Deliver a microwave for $20
• Deliver a toaster oven for $20

You might jump straight for the table and chairs, since that earns you the most money. However, once they are in your truck, there is no room for anything else, and so that's the only job you can do today. By the time you deliver the table and chairs and come back to the warehouse, other people will have done the other jobs.

On the other hand, you can fit the TV, the microwave, and the toaster oven all in your truck together. By taking multiple cheaper jobs, you actually end up with more money than taking the single expensive job.

Think of a bitcoin block like the truck in this analogy, and individual transactions like the various jobs. Although a transaction may pay more overall, it might be better for a miner to pick smaller transactions with a lower overall fee because they can squeeze more of them in to the finite space in a block.