02:47:15 <BusyBoredom[m]> If I'm not having a blond moment, it looks like Seraphis transactions with ring size 64 (which seems to be the most likely choice of ring size?) will be larger than our current transactions. The increase is obviously justified, but it is an increase nonetheless. Are there any improvements in the works to offset that increase somehow, or will it just be an unfortunate tradeoff? 
03:16:12 <UkoeHB> BusyBoredom[m]: There are no such improvements I am aware of.
03:30:28 <BusyBoredom[m]> Fair enough, thanks for the confirmation. I'm definitely still a fan of the ring size increase despite the minor size tradeoff, don't let me cast any doubt on that.
04:16:32 <ArticMine> We can go up to 256 ring size with Seraphis for a 3 in 3 out tx and still be below 3000 bytes the ref tx size for fees and scaling
04:16:52 <ArticMine> soort 2 in 2 out
04:19:15 <ArticMine> So it is just Nielsen's law here wit ha 1.5x increase in bandwidth per year. With a 2 in 2 out tx under 3000 bytes there is no need to change the fee structure and minimum node relay fee
04:21:06 <ArticMine> I actually believe there is strong case for at least 128 ring size here, especially if GPU verification can significantly reduce the verification time
10:37:37 <dEBRUYNE> ArticMine: 256 would have too much of an impact on verification time imo
21:23:00 <boogerlad[m]> even though the general trend over time is more compute power?
21:30:01 <Rucknium[m]> boogerlad: The question is who are we excluding if the computation requirements become too much for low-end hardware?
21:31:16 <boogerlad[m]> why wouldn't people with low end hardware just use a service like mymonero? tradeoffs have to be made somewhere
21:31:58 <boogerlad[m]> with janus b, I]'d say the tradeoff isn't too bad
21:34:34 <Rucknium[m]> Maybe. That's a normative question that must be discussed widely. We haven't even established the answers to the positive questions yet.
21:37:48 <boogerlad[m]> since you're here ruckinum, is there an estimated time / cost for a non parametric ospead?
21:58:27 <Rucknium[m]> Hard to estimate now. I'd say at best 6 months after OSPEAD is completed. At worst 18 months. That's not continuous work time. It may involve submission to an academic journal for instance, which could involve a lot of wait time.
22:00:06 <Rucknium[m]> The thing is, we may want to incorporate not just a parametric method, but also dynamic adjustment, enforcement of the distribution at the node level, and possible countermeasures against malicious spam. Developing a sound method that does that and giving it proper vetting would take a long time
22:02:51 <boogerlad[m]> would you say parametric ospead is a prerequisite to non parametric?
22:04:39 <Rucknium[m]> Some of the work that has to be done for a nonparametric approach will be done as part of developing OSPEAD. So there is not a full duplication of effort. 
22:05:14 <boogerlad[m]> nice :)