harutoooo The paper looks really interesting. I have a couple questions

What's the difference between n and m

Is m the number of real signers?

Okay sorry I reread it and yeah I figured it out

Why is it that only every other private key is linkable?

jeffro256[m]: he is alternating between the signing key and the commitment to zero for each input

(kind of confused me for a bit too)

Oh is the signature effectively using the commitment as r values?

This is the different point between PLSAG and CLSAG.

jeffro256: Thank you for checking my paper and nice questions.

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.

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.

UkoeHB: How does tx verification scale with number of cores / threads for seraphis?

probably similar to must threaded scaling, as linear as possible but typical scheduler overhead

ah that's good to hear! I thought some txs might depend on others due to ring signature members or something

> At ~10ms to verify a Seraphis tx with 128 ring size on a high-end CPU, you can verify 100 tx per second

considering that most people have a multicore cpu, I think this is a lower bound

oops, formatted incorrectly. first line is supposed to be a quote. second line not

oh I suppose that could make things complicated from an implementation point of view

not impossible, just annoying

what's the likelihood of that happening anyways?

(dependent txs bottlenecking multithreaded verification)

of implementing multithreaded verification? I guess it's isomorphic with the probability of someone getting excited to do it

sorry I meant what's the likelihood of dependent txs bottlenecking multithreaded verification, effectively forcing it to be single threaded

are shared ring signature members common?

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

chain data) then you need to abort and reset the cache without accidentally committing any invalid txs to the database.

how large of a cache are we talking here?

I'm curious if recent innovations such as amd's v-cache would help out with a gigantic l3 cache

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.

hot cache / RAM, whatever ^.^

oh I see, limited by ram and not l3

that's cool

then, what becomes the next bottleneck for tps after verification? storage capacity? storage speed? network bandwidth?

let me know if this sort of chat doesn't belong here

ArticMine: argues it is network bandwidth

you can see his monerotopia presentation about it monerodl.com/monerotopia/04-Artic-Mine

haha only because canada is a third world country in terms of internet service providers ;)

thank you for the link

Slide 13: am I reading this right? Monero's peak tps could go up to 6940 tps when limited by bandwidth?

Or does that not take into account the current limits of verification?

(Ignoring the limits on block growth - thinking purely in terms of "how fast can it go full-throttle")

I guess it can if you use a very very fast server. And if you wait enough, you'll probably get that eventually.

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?