Is there a way to determine the optimal size of a batched transaction to save on fees?

Question

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 that seems to confirm what I was thinking, and that all things being equal it will always save fees to add a new output.

Answer 1

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..).

Answer 2

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.