<UkoeHB> It might be possible to justify 128 using the squashed variant, which benefits a lot from batching. Needs careful thought. <--- This maybe close to optimal. One question I have is the specs of the computer processor that was used and if all the threads of the processor were used.

Absolutes do matter when considering ring size and how it translates into transactions per second for a given computing capability. This is important for scaling

Great work by the way

gingeropolous Do hanksyou have the processor specs? T

Do you have the processor specs. Thanks

has anyone done any research on what distribution past outputs have? If you subtract the gamma from the empirical, do you just get another gamma?

The question in my mind is at what TPS will certain common processors not be able to keep up with the network

yeah we can run that on various CPUs and get a full picture

ArticMine: I updated the issue with test context. It was run on one thread.

I think the general trend over time is more cores anyways, so since verification is parallelizable, 128 is acceptable

*ring size 128

is it already parallelized?

Not my PoC, idk about existing impl.

ArticMine I think the TPS question is functionally closer to ‘inputs per second’, since validating tx inputs dominates tx verification time.

And a tx with many inputs is way more expensive than one with few.

But there are fixed costs too, so it isn’t completely trivial.

<gingeropolous> yeah we can run that on various CPUs and get a full picture <---- Yes that and core leads would be excellent

One could use the existing blockchain data to estimate the average number of inputs per tx. Ballpark on average I suspect about 2

A high end CPU can have say 16 cores with 24 threads. so parallel processing is critical 20 ms for a 2 in tx means 50 tx /sec on one thread for 1 sec verification time. For 24 threads that is 1200 TPS for 1 sec verification time.

I realize this is very high end

but still with say 10 sec verification time we are well above the average VISA tx rate, but below the peak

This is why getting a real handle on the is important

Has anyone ever thought of writing GPU accelerated verifier?

"<@ArticMine> One could use the existing blockchain data to estimate the average number of inputs per tx. Ballpark on average I suspect about 2" - I checked and up to height 2491099 I got 3 for the average

sorry let me clarify, if you meant "mean" by average, 3. otherwise the most common is 1, followed by 2

"Has anyone ever thought of writing GPU accelerated verifier?", "teddit.net/r/Monero/comments/f5d3k3…ea_pitch_gpuaccelerated_wallet_sync" yes

and it will be needed despite of the "useful" comments on reddit since cpu must be dedicated to pow

and even mobile devices have gpus

It has been on my list of things to do for a long time (GPU acceleration for wallet sync). One day I'll find time :)

<wfaressuissia[m]> ""Has anyone ever thought of..." <- Sounds like a great thing to open a bounty for 🙂

I'll get that fired up today!

That thing will take few months of implementation, it isn't easy work

but i feel this supports the notion that we should consider future possible optimizations when selecting a ringsize

it can be technically impossible to fork. it is always technically possible to optimize. well wtf do i know i write bash scripts.

Added an issue for Seraphis address schemes: monero-project/research-lab #92