Topic: Calculating the size of a transaction (Read 258 times)

That's not quite accurate. For segwit, since the signature is moved to witness data, this field is left empty, and the preceeding script length field will be 0x00.

Here's a 998-of-999 taproot transaction: https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73

   

•    inputs[j].script_signature has length script_length bytes and is big endian, it's on legacy and segwit.

Only if you spend by TapScript, you can see more details, but then it is more expensive, and less private.

Do you have any examples I could look into?

Perhaps a mempool.space link with such a transaction?

The perfect choice is a huge multisig, hidden in a single Taproot address. Then, you can have for example 1000-of-1000 multisig, and then if there is 10 BTC on such address, then you don't know if everyone owns 0.01 BTC, or how exactly this amount is splitted between all participants. But still, this is the song of the future, for now, we have widely deployed 2-of-2 multisigs, and not much more than that. But of course, more things are possible, even if we are not there yet.

Ideally spend from taproot addresses and send to native segwit addresses, but in reality just use either native segwit or taproot, which ever you prefer, since the difference is very small.

Therefore you are kind of obligated to use specific UTXO sizes.

Minimize the number of inputs and number of outputs. Ideally spend from taproot addresses and send to native segwit addresses, but in reality just use either native segwit or taproot, which ever you prefer, since the difference is very small.

For 1 input and 2 outputs for segwit 0, the result should be 1*68 + 2*31 + 10 = 140 vB. Am I wrong?

1. It is always better (but of course rarely possible) to spend a whole UTXO, since it is the only way to have 1 and not 2+ outputs. Correct?

2. The amount of sats doesn't count at all, as it is always represented by 8 bytes of information in the output. Correct? I kinda knew that bit already, but I ask for clarification.

Can you give 2-3 tips to follow if I wanted to create better transactions in terms of weight? Take for granted that I use coin-control by default, so I always choose the UTXOs I spend. What I want is a way to treat them more wisely.

<~>

Formula:
For legacy address: vbyte= Input*148 + output*34 + 10 plus or minus input
For nested segwit: vbyte= Input*93 + output*32 + 10 plus or minus input
For segwit version 0: vbyte= Input*68 + output*31 + 10 plus or minus input
For pay-to-taproot: vbyte= Input*57.5 + output*43 + 10 plus or minus input

ScriptSigs will vary depending on a number of factors such as address type, locking script, grinding for small R values, and so on. These will also be calculated differently for segwit inputs given this is witness data. (Transactions spending segwit inputs will also need a segwit flag in the header). A standard P2PKH ScriptSig will typically be ~107 bytes. A standard P2WPKH segwit ScriptSig will typically be 107 vbytes, which will then work out to 26.75 bytes.

ScriptPubKeys will vary depending on the output type:
P2PKH - 25 bytes
P2SH - 23 bytes
P2WPKH - 22 bytes
P2WSH - 34 bytes
P2TR - 34 bytes

Here is a very thorough explanation which might help you further: https://bitcoin.stackexchange.com/questions/92689/how-is-the-size-of-a-bitcoin-transaction-calculated

Variable length integer

Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length. Longer numbers are encoded in little endian.
If you're reading the Satoshi client code (BitcoinQT) it refers to this encoding as a "CompactSize". Modern Bitcoin Core also has the VARINT macro which implements an even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). VARINT is not a part of the protocol.

Legacy addresses starts from 1
Nested segwit starts from 3 (although not only nested segwit starts from 3)
Segwit version 0 starts from bc1q
Segwit version 1 starts from bc1p (pay-to-taproot)

This is the formula necessary for the calculation:

Formula:
For legacy address: vbyte= Input*148 + output*34 + 10 plus or minus input
For nested segwit: vbyte= Input*93 + output*32 + 10 plus or minus input
For segwit version 0: vbyte= Input*68 + output*31 + 10 plus or minus input
For pay-to-taproot: vbyte= Input*57.5 + output*43 + 10 plus or minus input


To know more about the input and output virtual size: https://bitcoinops.org/en/tools/calc-size/
To know more about the transaction virtual size: https://jlopp.github.io/bitcoin-transaction-size-calculator/
For mempool (beginners): https://mempool.space/
Mempool for advanced users: https://jochen-hoenicke.de/queue/#BTC%20(default%20mempool),24h,weight

For example:
If you use the vbyte calculator or that formula above for 1 input and 2 outputs for native segwit addresses, you will get 110 vbyte as the virtual size of 1 input 2 outputs transaction.

To check the fee rate, click on the above second to the last, or last link.

Assuming the fee rate is 5 sat/vbyte.

Fee rate = fee ÷ vbyte

Fee = fee rate * vbyte

Fee = 5 * 110

Fee = 550 sat (0.0000055 BTC). I mean for 1 input and 2 outputs for segwit version 0.


Which means the higher the fee rate, the higher the fee. As mempool is becoming more congested, the fee rate will increase and the fee will increase.

Also if you understand ehat I explained above, you will noticed that as the input count is increasing, the fee will also increase.

Also as the output count is increasing, the fee is also increasing. But if you send to two different addresses separately, the fee would be more. So we can still say increase in the output will make the fee to decrease, despite that the fee is increasing, but lower than sending to each addresses separately.

From the virtual sizes, you can also know that you can save more in fee if you use segwit version 0 and pay-to-taproot addresses while legacy addresses have the highest fee.

Also you will know that pay-to-taproot will be good for consolidation, while segwit version 0 for paying to many addresses.