Topic: 2 inputs - 2 outputs - different size? (Read 296 times)

The amount of BTC transacted has no "direct" relationship to the transaction fee.

The only time the amount sent becomes relevant, is when the amount being sent (+fee) is greater than the largest available UTXO that the wallet can use as an input to the transaction. Then the wallet would need to include more inputs, which increases the transaction data size, which increases the fee.

Ie. Wallet (balance of 0.7) has UTXOs of 0.1, 0.2 and 0.4 and you want to send 0.5... it needs to use at least 2 of the UTXOs to complete the transaction.

Whereas if your wallet (balance of 0.7) has UTXOs of 0.6 and 0.1, and you want to send 0.5, you could do it with just 1 input.

Following this logic, with your example, if you had a wallet balance of 1000 BTC with just one UTXO, sending 0.1 or 100 BTC should theoretically use the same fee. Only 1 input used.

Thank you.
So if I only spend from addresses I generated using bitcoin-core, it doesn't matter to what address I send the amount, my fee will be ~ 10 + (148 * number of inputs) + (34 * number of outputs (including change address))?

And one last thing. In the fee size, does it matter if I send 0.1 bitcoin or 100 bitcoin? Or it is totally unrelated to the amount I am spending.

Assuming we are talking about the traditional non-segWit transactions...

The output size (in the transaction that pays you) will be 34 bytes.

• 8 bytes: quantity satoshis being sent
• 1 byte:   OP_DUP
• 1 bytes: OP_HASH160
• 1 byte: length of output script
• 1 byte: size of public key hash
• 20 bytes: hash of public key
• 1 byte: OP_EQUALVERIFY
• 1 byte: OP_CHECKSIG

When you create a transaction that spends that output, you will reference that output in your list of inputs.  In that case, the input size (in the transaction where you spend those bitcoins) will be 148 ( + / - 1) bytes.

• 32 bytes: hash of the transaction where you received the bitcoins
• 4 bytes:   index of output in the transaction where you received the bitcoins
• 1 byte: length of input script
• 75 (+ / - 1 byte) bytes: ECDSA signature
• 32 bytes: public key (assuming you generated your address from a compressed key)
• 4 bytes: sequence number

What about them?


Yes.  And they will need to take that into consideration when they spend the outputs that they receive from you.  It won't matter to you, since you are creating outputs with the address that you received from them. The inputs for your transaction come from the addresses that you created when you received the bitcoins.

Thanks for your comments.
For example, if I generate new addresses using bitcoin core and get paid to these addresses, the compressed output size when spending the coins will always be 148 bytes (+ / - 1) per output? So, when I spend the coins received to any of these addresses, I can assume that 1 output = 148 bytes?
What about inputs? Is it possible that someone is sending me an address where the input when spending coins to is not 34 bytes?

Sorry for my silly questions, just trying to learn.

First of all, your calculation is wrong.  Assuming you are talking about the traditional payments using compressed key bitcoin addresses that start with a 1 (P2PKH outputs), then the inputs are 148 bytes each (plus or minus 1 byte), not 146 bytes.

There is a 1 byte variability in the exact size of the input due to variablity in the size of the ECDSA signature.


The original outputs were pay-to-public-key (P2PK) outputs.  They did not use bitcoin addresses, and they did not hash the public key.  The recipient needed to supply their entire ECDSA public key, and the sender needed to build the transaction appropriately.

Eventually the concept of hashing the public key and encoding the output type as an "address" was introduced.  Those are pay-to-public-key-hash (P2PKH) outputs.  They are the traditional address starting with a 1 that you are accustomed to.  Initially, these addresses were generated using an uncompressed public key.  As such, the input that is generated when spending these outputs are 32 bytes larger (180 bytes).

Then someone realized that only half of the public key was actually needed.  The address format remains the same, but the spender can reduce the size of their inputs by 32 bytes to only 148 bytes since they can supply the compressed public key. Those are ALSO pay-to-public-key-hash (P2PKH) outputs, and result in an address starting with a 1.  There is no way to know when looking at an output whether it is a compressed key or uncompressed key unless you have access to the public key itself.

Eventually the concept of hashing the output script was introduced.  This allowed any script to be represented as an address (addresses starting with a 3).  These are called pay-to-script-hash (P2SH) outputs.  They are often used for multi-sig, but can also be used for any valid script.  The size of the input when spending these outputs depends entirely on the structure of the script that was hashed to generate the address.

While it is less common, it is also possible to simply use a non-standard script in the output.  In that case, the size of the output (and the size of the input that spends it) would depend on the contents of that script.

The 180 byte uncompressed key input, 148 compressed key input, and 34 byte output values all assume that you are talking about P2PKH outputs (the outputs that result in a bitcoin address that starts with a 1). That's what the vast majority of users are talking about when they ask about transaction sizes.

Thanks but I do not quite understand what you mean by "a different type of output". How can an output be different than another output? Can you please explain?
And what is that specific type of output? Do you mean if the 17ee6117041ee734e7d7d80cdadc475bf1f623984bd0346fc2192f2f062fd5c3 transaction would have sent the coins to other outputs (let's suppose to the outputs of the 2nd transaction) the size would have been different?

There are multiple types of inputs and outputs, Your formula only works for one specific type of output and its spend in an input. The above transaction spends from a different type of output and creates a different type of output so your formula does not hold.

As far as I know, the size of a transaction is based on number of inputs (input * 146) and number of outputs (output * 34) + about 10 bytes. It is not based on the transactioned amount, right?
How come that 2 transactions with the same number of inputs and outputs have different size?

For example check this one:
https://blockexplorer.com/tx/17ee6117041ee734e7d7d80cdadc475bf1f623984bd0346fc2192f2f062fd5c3
Blockexplorer states 371 bytes for this transaction which seems to be correct based on the above calculation: 146 * 2 + 34 * 2 + 10 = 370.

And now check this one:
https://blockexplorer.com/tx/f83eac6755eb530ae7640684e887f8083da331c0c465cc16d3f10a179eb21594
Here, blockexplorer states 663 bytes as the transaction size which is nearly double than the 370 bytes.

What is wrong with my assumption?