18:19:40 <m-relay> <k​ayabanerve:matrix.org> I wrote a summary and statement piece on MAX_INPUTS (and a few related topics): https://gist.github.com/kayabaNerve/dbbadf1f2b0f4e04732fc5ac559745b7
18:22:47 <m-relay> <k​ayabanerve:matrix.org> ArticMine: ofrnxmr Lyza sech1 dave.jp midipoet blurt4949 Rucknium @ anyone else who participated in this discussion recently and cares
18:58:14 <m-relay> <s​yntheticbird:monero.social> Thx for the summary.
19:29:08 <midipoet> kayabanerve: thanks for the info, i appreciate it. I'll have to try and read it a few times to grasp the intracacies. It seems MAX_IN=8 is high enough for the vast majority of users and use-cases. Not really sure i fully understand the MAX_OUT discussions to be honest. 
19:38:26 <m-relay> <k​ayabanerve:matrix.org> midipoet: If MAX_OUTPUTS == 2 * MAX_INPUTS, I can send you one transaction's worth of outputs which takes you two transaction's worth of inputs to consolidate.
19:38:52 <m-relay> <k​ayabanerve:matrix.org> It's an asymmetry between cost incurred to trigger and cost incurred which could be considered a DoS.
19:39:43 <m-relay> <k​ayabanerve:matrix.org> I'm not saying it's the end of the world, it's just a poor design decision.
19:41:52 <midipoet> Oh, now i understand it better. thank you for that. 
23:30:35 <m-relay> <d​ave.jp:matrix.org> Are we limiting max input to 4/8 for Transaction uniformity ?
23:40:45 <m-relay> <o​frnxmr:monero.social> > Right now, ~220 inputs can be aggregated in a single transaction
23:41:16 <m-relay> <o​frnxmr:monero.social> kayabanerve @kayabanerve:matrix.org:  this isn't accurate, as we actually limit to ~2/3 of 149kb (100kb)
23:41:36 <m-relay> <o​frnxmr:monero.social> Aprox 146 inputs
23:48:24 <m-relay> <o​frnxmr:monero.social> > 97.67% of transactions used less than or exactly 8 inputs. 97.71% of transactions used less than or exactly 8 outputs.
23:48:25 <m-relay> <o​frnxmr:monero.social> Rucknium:  this goes back to 2019. I thought more recent number indicated ~30% of tx were 16 out