03:56:59 <jeffro256[m]> harutoooo The paper looks really interesting. I have a couple questions
03:57:05 <jeffro256[m]> What's the difference between n and m
03:57:17 <jeffro256[m]> Is m the number of real signers?
04:02:23 <jeffro256[m]> Okay sorry I reread it and yeah I figured it out
04:09:10 <jeffro256[m]> Why is it that only every other private key is linkable?
04:36:50 <UkoeHB> jeffro256[m]: he is alternating between the signing key and the commitment to zero for each input
04:37:08 <UkoeHB> (kind of confused me for a bit too)
05:18:14 <jeffro256[m]> Oh is the signature effectively using the commitment as r values?
05:29:57 * harutoooo[m] posted a file: (66KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sHgyfDTZnbqGCocEXivwHxtv/plsag.pdf >
05:31:39 <harutoooo[m]> This is the different point between PLSAG and CLSAG. 
05:32:09 <harutoooo[m]> jeffro256: Thank you for checking my paper and nice questions.
05:42:08 <harutoooo[m]> In PLSAG, linkability can be added to the S line when calculating the key images on the first step of the signing algorithm. However, the larger the number of lines that add linkability, the larger the signature size.
05:46:33 <harutoooo[m]> In Monero, I consider odd-numbered lines are for proving the private keys of inputTx, and even-numbered lines are for the commitment to zero.
20:06:54 <boogerlad[m]> UkoeHB: How does tx verification scale with number of cores / threads for seraphis?
20:16:15 <UkoeHB> probably similar to must threaded scaling, as linear as possible but typical scheduler overhead
20:19:07 <boogerlad[m]> ah that's good to hear! I thought some txs might depend on others due to ring signature members or something
20:19:53 <boogerlad[m]> > At ~10ms to verify a Seraphis tx with 128 ring size on a high-end CPU, you can verify 100 tx per second
20:19:53 <boogerlad[m]> considering that most people have a multicore cpu, I think this is a lower bound
20:20:32 <boogerlad[m]> oops, formatted incorrectly. first line is supposed to be a quote. second line not
20:22:00 <UkoeHB> oh I suppose that could make things complicated from an implementation point of view
20:22:12 <UkoeHB> not impossible, just annoying
20:23:02 <boogerlad[m]> what's the likelihood of that happening anyways?
20:23:24 <boogerlad[m]> (dependent txs bottlenecking multithreaded verification)
20:23:45 <UkoeHB> of implementing multithreaded verification? I guess it's isomorphic with the probability of someone getting excited to do it
20:26:23 <boogerlad[m]> sorry I meant what's the likelihood of dependent txs bottlenecking multithreaded verification, effectively forcing it to be single threaded
20:26:32 <boogerlad[m]> are shared ring signature members common?
20:26:39 <UkoeHB> It's not a bottleneck issue, it's an issue of how you update the reference set. If you are verifying a tx that depends on a tx that is not in the ledger (e.g. it is being validated in another thread), then your ring member references have to be drawn from some kind of hot cache (maybe you hot cache a large chunk of txs while validating them in parallel). If some tx is invalid (very unlikely if you are re-validating 
20:26:39 <UkoeHB> chain data) then you need to abort and reset the cache without accidentally committing any invalid txs to the database.
20:28:23 <boogerlad[m]> how large of a cache are we talking here?
20:28:48 <boogerlad[m]> I'm curious if recent innovations such as amd's v-cache would help out with a gigantic l3 cache
20:30:22 <UkoeHB> Large enough to fit all the txs you are validating I guess (you need all these txs to be hot cached anyway, since you are validating them). If it's a read-only cache while validator threads are working on it, it shouldn't be a problem.
20:31:26 <UkoeHB> hot cache / RAM, whatever ^.^
20:32:03 <boogerlad[m]> oh I see, limited by ram and not l3
20:32:09 <boogerlad[m]> that's cool
20:33:03 <boogerlad[m]> then, what becomes the next bottleneck for tps after verification? storage capacity? storage speed? network bandwidth?
20:33:16 <boogerlad[m]> let me know if this sort of chat doesn't belong here
20:34:14 <UkoeHB> ArticMine: argues it is network bandwidth
20:34:46 <UkoeHB> you can see his monerotopia presentation about it https://monerodl.com/monerotopia/04-Artic-Mine/
20:35:01 <boogerlad[m]> haha only because canada is a third world country in terms of internet service providers ;)
20:35:14 <boogerlad[m]> thank you for the link 
20:45:56 <merope> Slide 13: am I reading this right? Monero's peak tps could go up to 6940 tps when limited by bandwidth?
20:46:17 <merope> Or does that not take into account the current limits of verification?
20:47:13 <merope> (Ignoring the limits on block growth - thinking purely in terms of "how fast can it go full-throttle")
20:55:17 <moneromooo> I guess it can if you use a very very fast server. And if you wait enough, you'll probably get that eventually.
21:08:23 <boogerlad[m]> ArticMine: what is the difference between peak and mean regarding "2022: Stress test: 6940 tps Mean: 278 tps". given that there are no bottlenecks, why couldn't 6940tps be sustained?