increasing uniformity of number of inputs/outputs

[chaserene]

this issue is inspired by @tevador's comments in various places about transaction uniformity, e.g. in #96 (comment) or in monero-project/monero#6668 (comment).

the idea is that letting users/wallets to choose the number of inputs and outputs makes it easier to categorize transactions and fragment the anonymity pool ("anonymity puddles"). this fragmentation has already been reduced by mandating a dummy output in transactions that would otherwise have only one. the number of outputs is already mandated to be ≥ 2.

inputs

#96 is about the implementation of dummy inputs, a prerequisite to do similar as the above to inputs, but I think the topic has wider implications. to start with a quote from #96 (comment):

We can thus extend the idea and mandate all transactions to have the same number of outputs and the same number of inputs.

I agree this would be the ideal. however, it would lead to scenarios where, if you wanted to send an amount and the sum value of your enote set was sufficient (=you have enough money), but it has no combination of a mandated number of enotes whose sum value is sufficient (=you have many low-value ones), you are forced to create "join" transactions until you have a set that contains at least one sufficient combination. worse, due to the 10-block lock, you are forced to wait an additional ~20 minutes with each "join" before you can make the transaction you originally intended. this would also result in more, easily distinguishable, transaction paths that spend right after the 10-block lock, which is also not great.

(the frequency of this could be reduced by increasing the mandated number of input enotes, but at the cost of larger transactions and higher verification times. besides, anything other than 2 seems arbitrary. if the costs of additional inputs ever becomes negligible, it may be worthwhile to revisit this. nevertheless, no number high enough can eliminate this problem.)

however, increasing the uniformity of number of inputs/outputs seems viable. it's already been done with outputs.

what do you think about mandating at least 2 inputs (more would be allowed)? it would unify two large anonymity puddles (1-input and 2-input transactions). furthermore, it would offer the uniformity of two current use cases connected to privacy in Monero: 1) where people deliberately make only 1-input transactions to reduce transaction linkability; and 2) where people deliberately make "join" transactions so that they can later achieve the same ability with their (currently insufficient) enote set as the former group.

I acknowledge that even this number isn't free of arbitrariness ("wouldn't 3 be even better?"), but as long as Monero uses the enote model, anonymity pool fragmentation due to input/output arity doesn't seem to be eliminable without breaking general UX, only reducible. (could eliminating the N-block lock change this? I'm not sure.) I also know that a privacy coin ideally shouldn't expect users to act with the underlying transaction model in mind. however, with the EABE/Knacc attack and churning as a potential defense against it, it already sort-of-requires people who want better privacy to modify their transacting behavior according to Monero's transaction model.

a definite downside would be larger transaction sizes and higher verification times, since all transactions that had only one real input would have another dummy one. is this worthwhile a trade-off? if not, at what point does it become one?

outputs

non-mining reward outputs are currently constrained to 2--16. for general use cases, I don't see the need for more than 2 (payment, change), but I'm sure and I do see on the blockchain that there are use cases for more.

who and what such use cases do we know of? how much of a disadvantage would it be for them to be restrained to less, e.g. 2, outputs? is leaving their use case intact more valuable to the goals of Monero than the increasing of transaction uniformity?

the use cases I'm aware of:

• Monerujo PocketChange initiation transactions

applicability to network era

if any of the above changes are worthwhile, are they relevant only in the context of Seraphis, or would it make sense to act on them while Monero is still using Cryptonote?