<blockquote>
<p>But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.</p>
</blockquote>
<p>The addition of another input does not matter, as it would have to be included in the next transaction too anyway.</p>
<p>In any way, a second stage transaction will always be more costy than a single batching transaction as you would duplicate the (non-witness!) meta bytes (version, n° of input, n° of outputs, locktime, etc..).</p>

CC BY-SA 4.0
2020-06-25T11:51:04.740Z
Ok, so it means that no matter what it is always better to add one more recipient if possible? I know it's a bit of the scope of my question, but shouldn't I also consider the change output I'll get? I mean if adding one more output mean that I will get a very small UTXO or even dust as a change, that I'd need to consolidate after that, maybe I'd rather not batch one more output, what do you think?
Sosthène
CC BY-SA 4.0
2020-06-25T13:33:12.953Z
I think that the change output is actually an argument *for* batching transactions. The only alternative to batching is using multiple transactions, which implies many change outputs (and more inputs in later stages).
Antoine Poinsot
CC BY-SA 4.0
2020-06-25T11:45:58.283Z
2020-06-25T11:45:58.283Z
Antoine Poinsot
<p>What you save now by minimizing no of input, maximizing no of output, will become expenses later on for the output owner, where the number of input getting more and more, and the value of each input getting smaller and smaller.</p>
<p>If the output owner is someone else, then continue with minimizing no of input, maximizing no of output. Hot potato fee. I just minimize my $expenses, these outputs belongs to someone else, they will have to take care of the spending expenses later on.</p>
<p>If you said that &quot;<em><strong>But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input.</strong></em>&quot; then what you should actually consider is consolidating your output into bigger input when the fee is low. Bigger input means more $fund in-flight during transaction.</p>
<p>If the output owner is you, then you should consider a different strategy.</p>

CC BY-SA 4.0
2020-06-25T23:57:07.740Z
I need to think through thoroughly about what will be the different strategy b4 i edit the answer again.!
Cisco Mmu
CC BY-SA 4.0
2020-06-25T16:59:58.037Z
2020-06-25T23:51:30.740Z
2020-06-25T23:51:30.740Z
Cisco Mmu
<p>I've been looking at other questions about fees and batching, but it seems no one asked if there is some way to determine the optimal size of a transaction to save on fees (assuming all inputs are spending from segwit native UTXOs for simplicity).</p>
<p>To expand a bit on what I have in mind: I need to pay various amounts to different people (let's consider their number can be anywhere between 1 and infinite), and I guess that by making one &quot;big&quot; transaction paying them all at once instead of 1 transaction for each of them I can save on fees. But is it the more people I can add up in the same transaction the better, or would I save less at some point if my transaction keeps getting bigger? Is there some model to calculate the &quot;optimal&quot; size for my batched transaction, or maybe it doesn't make sense?</p>
<p>Here's my best guess for now: adding more people means really adding outputs, which makes the transaction grow linearily (assuming all ouputs are pretty standard and roughly of the same size), so assuming the fees are split between each receivers the more people you can onboard on the same transaction the cheaper it gets for everyone.</p>
<p>But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.</p>
<p>[EDIT] I came across <a href="https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb" rel="noreferrer">this article</a> that seems to confirm what I was thinking, and that all things being equal it will always save fees to add a new output.</p>

<transaction-fees><coin-selection><payment-batching>
Is there a way to determine the optimal size of a batched transaction to save on fees?
Sosthène
# Is there a way to determine the optimal size of a batched transaction to save on fees?

(Asked by: username_0 on 2020-06-25)

I've been looking at other questions about fees and batching, but it seems no one asked if there is some way to determine the optimal size of a transaction to save on fees (assuming all inputs are spending from segwit native UTXOs for simplicity).

To expand a bit on what I have in mind: I need to pay various amounts to different people (let's consider their number can be anywhere between 1 and infinite), and I guess that by making one "big" transaction paying them all at once instead of 1 transaction for each of them I can save on fees. But is it the more people I can add up in the same transaction the better, or would I save less at some point if my transaction keeps getting bigger? Is there some model to calculate the "optimal" size for my batched transaction, or maybe it doesn't make sense?

Here's my best guess for now: adding more people means really adding outputs, which makes the transaction grow linearily (assuming all ouputs are pretty standard and roughly of the same size), so assuming the fees are split between each receivers the more people you can onboard on the same transaction the cheaper it gets for everyone.

But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.

[EDIT] I came across [this article](https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb) that seems to confirm what I was thinking, and that all things being equal it will always save fees to add a new output.

**Tags:** transaction-fees, coin-selection, payment-batching


---

## 2 answers

### Answer by username_1 on 2020-06-25. Score: 3

> But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I'd rather just stop it and send the batch at this point.

The addition of another input does not matter, as it would have to be included in the next transaction too anyway.

In any way, a second stage transaction will always be more costy than a single batching transaction as you would duplicate the (non-witness!) meta bytes (version, n° of input, n° of outputs, locktime, etc..).

> **Comments:**
> **username_0**: Ok, so it means that no matter what it is always better to add one more recipient if possible? I know it's a bit of the scope of my question, but shouldn't I also consider the change output I'll get? I mean if adding one more output mean that I will get a very small UTXO or even dust as a change, that I'd need to consolidate after that, maybe I'd rather not batch one more output, what do you think?  
> **username_1**: I think that the change output is actually an argument *for* batching transactions. The only alternative to batching is using multiple transactions, which implies many change outputs (and more inputs in later stages).  

---

### Answer by username_2 on 2020-06-25. Score: 0

What you save now by minimizing no of input, maximizing no of output, will become expenses later on for the output owner, where the number of input getting more and more, and the value of each input getting smaller and smaller.

If the output owner is someone else, then continue with minimizing no of input, maximizing no of output. Hot potato fee. I just minimize my $expenses, these outputs belongs to someone else, they will have to take care of the spending expenses later on.

If you said that "***But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input.***" then what you should actually consider is consolidating your output into bigger input when the fee is low. Bigger input means more $fund in-flight during transaction.

If the output owner is you, then you should consider a different strategy.

> **Comments:**
> **username_2**: I need to think through thoroughly about what will be the different strategy b4 i edit the answer again.!  

---

