01:22:38 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. 01:24:35 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 01:24:47 Great work by the way 01:25:47 gingeropolous Do hanksyou have the processor specs? T 01:26:38 Do you have the processor specs. Thanks 01:28:01 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? 01:29:07 The question in my mind is at what TPS will certain common processors not be able to keep up with the network 01:35:43 yeah we can run that on various CPUs and get a full picture 01:41:39 ArticMine: I updated the issue with test context. It was run on one thread. 01:42:37 I think the general trend over time is more cores anyways, so since verification is parallelizable, 128 is acceptable 01:42:38 *ring size 128 01:44:29 is it already parallelized? 01:44:53 Not my PoC, idk about existing impl. 04:43:15 ArticMine I think the TPS question is functionally closer to ‘inputs per second’, since validating tx inputs dominates tx verification time. 04:43:37 And a tx with many inputs is way more expensive than one with few. 04:45:02 But there are fixed costs too, so it isn’t completely trivial. 06:06:46 yeah we can run that on various CPUs and get a full picture <---- Yes that and core leads would be excellent 06:08:24 One could use the existing blockchain data to estimate the average number of inputs per tx. Ballpark on average I suspect about 2 06:17:09 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. 06:17:21 I realize this is very high end 06:19:38 but still with say 10 sec verification time we are well above the average VISA tx rate, but below the peak 06:20:37 This is why getting a real handle on the is important 06:25:32 Has anyone ever thought of writing GPU accelerated verifier? 07:39:07 "<@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 07:45:59 sorry let me clarify, if you meant "mean" by average, 3. otherwise the most common is 1, followed by 2 10:53:25 "Has anyone ever thought of writing GPU accelerated verifier?", "https://teddit.net/r/Monero/comments/f5d3k3/idea_pitch_gpuaccelerated_wallet_sync/" yes 10:54:34 and it will be needed despite of the "useful" comments on reddit since cpu must be dedicated to pow 10:54:44 and even mobile devices have gpus 11:17:35 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 :) 12:53:39 ""Has anyone ever thought of..." <- Sounds like a great thing to open a bounty for 🙂 12:53:39 I'll get that fired up today! 13:38:39 That thing will take few months of implementation, it isn't easy work 14:10:53 but i feel this supports the notion that we should consider future possible optimizations when selecting a ringsize 14:14:56 it can be technically impossible to fork. it is always technically possible to optimize. well wtf do i know i write bash scripts. 16:47:51 Added an issue for Seraphis address schemes: https://github.com/monero-project/research-lab/issues/92