Transactions outputs

There is one point in the Transactions chapter that is not clear to me and I would like to have a little more explanation. In Ivan’s video he always talks about multiple outputs in 1 tx. But if I want to execute 3 transactions to 3 different people, I do it in 3 times! I send 0.1btc to my sister 0.1btc to a friend and 0.1btc to a web store. That’s 3 separate tx with 1x output each time! Can someone give a example how I can pay 3 or more people with 1 tx or is this form of tx not possible for a normal user?

1 Like

@dr_Rex hello sir, this point depend on the wallet software your are using to it, some wallets will have commands to create many transactions on the same output, for the blockchain, is just another output with many transactions request that will be appended in the next block.

Heres a video has an example: https://www.youtube.com/watch?v=McSVXIJw6FI

3 Likes

Thanks for this info this is the first time since i’m in crypto (2017) that i’ve heard about this option. Now everything’s clear :wink:

1 Like

@thecil

Just out of interest what would the rough % saving in transaction fees be, for each transaction you don’t send separately, but which you instead include as one of the multiple outputs in one single transaction?

I imagine this could vary depending on the size of the transaction in terms of data sent, but does anyone have any idea of an approximate saving?

I do realise that you wouldn’t save 100% of the cost of sending separately, because for each additional output you add to the single transaction, its size will increase and therefore the cost. But wouldn’t this increase always be a certain % of the cost of sending separately (from which we can then calculate a % saving?)

1 Like

from my understanding, it will cost you the same sat/byte if you send one or many at the same time.
the sat/byte cost is per transaction request, the ability of a wallet to build multiple transactions into 1 request is an internal function, at the blockchain level, each transaction for different address will have each a sat/byte cost. The sat/byte cost is driven by miners and mempool status at the moment you send a transaction request.

Lets say in example 20 sat/byte, byte cost per transaction is 192bytes , so it will be:

[20sat*192bytes]*[# of transactions] = total fee.

Example: i want to send btc to 10 different addresses:

[20sat*192byte]*[10] = 38400 sats (0.00038400 btc)

is not about saving in cost of transaction, is about saving time on sending to multiple address at once, paying a total fee for each transaction your requesting. (on the example, 1 transaction will cost you 3840 sats [0.00003840btc])

Please, if im wrong, just let me know, im learning like all of us too :upside_down_face:

mmm… my understanding is that if you use 1 UTXO to send to, say, 10 addresses (11 if you have change being sent back to yourself), then this is classed as just 1 transaction; whereas if you send to all 10 addresses separately, you’ll have 10 transactions (and as you will also be potentially having change sent back to your own address after each one, each transaction will have 2 outputs).

I agree with you that…

… so this is a variable that makes calculating any difference in cost impossible to do precisely, because the sats/byte will probably change over the course of sending 10 separate txs. But let’s just assume that it remains constant for the purposes of calculating any difference in cost due to differences in overall tx byte size.

Won’t the total number of bytes sent in 1 single “bundled” tx (1 input & 11 outputs) be less than the overall total bytes sent over 10 separate small txs (10 inputs & 20 outputs, assuming change is sent back to your own address in each)? If so, then assuming a constant sats/byte cost, the single “bundled” tx should have a lower overall cost than the 10 separate small txs — the cost saving due to less data sent overall, as a result of less overall tx inputs and outputs.

However, like you, I’m learning too :wink: so happy to have someone explain to me why I’m wrong, and that you’re right in that it…

Obviously, you are right that there is definitely a time saving advantage :+1:

Interesting discussion! :smiley:

1 Like

assuming that sat/byte cost remains constant (for example purposes), in theory it should be a saving cost, since it builds has you said 1 bundled UTXO, meaning with 1 hash of a transacion request should be enough to save cost on it.

Im marking this post because i think we might do some testing on the testnet just to clear doubts on this.

Probably would be a saving cost at the end, its kinda logic to have it, unless each transaction must have a single cost, whether you send many or 1.

1 Like

@Fabrice
I think you’ll enjoy this one! :muscle: Would be great to hear what you think… :thinking:
:hole: :rabbit2:

Didn’t read everything, but you need to sign every utxo with unlocking scripts. so It all depends on how Many inputs and outputs and to wich addresses. If you send from a legacy address every signiture for each utxo will be calculated in the size. It all depends on the scripts. Are the UTXO’s on a legacy address (P2PKH) pay to pubkey hash. Or segwit compatible (P2SH) Pay to script hash, or
Segwit native (Bech32)
But I didn’t read everything yet. (I saw numbers etcetera wich I should check) and I’m also still learning in the lower end of the rabbit hole :grin: