02:16:45 jberman: where can I read about the competition? 02:24:12 @binaryFate: all the details: https://github.com/j-berman/fcmp-plus-plus-optimization-competition 02:24:25 The proposed prize is 250 XMR for the winner for ec-divisors, 100 XMR for helioselene 02:25:03 ec-divisors is a core component of FCMP++ proving that currently takes on the order of seconds to run 02:25:59 (on the order of seconds) per block or per tx? 02:26:03 helioselene is the Elliptic Curve lib for the curves Helios and Selene, which are the curves used in the curve tree in FCMP++, and affects all aspects of FCMP++ (verifying, proving, node sync, wallet sync) 02:26:16 proving = constructing tx = in your wallet 02:27:38 👍 05:24:39 Made changes to the contest as discussed: 05:24:40 - License now only allows MIT (rule #2) 05:24:42 - As per kayabanerve kayabanerve suggestion, benchmarked `ScalarDecomposition::new` and `scalar_mul_divisor` together: https://github.com/j-berman/fcmp-plus-plus-optimization-competition/blob/9cea257d93631876e01988dfb710999dd484dc33/ec-divisors-contest/src/lib.rs#L32-L40 05:25:18 kayabanerve: I think it makes sense *not* to weigh new and scalar_mul_divisor 11/12, and instead to just bench the single call to each, because the only time we call the functions in a place where the divisor can't be pre-calculated / cached (when re-calculating the last pseudo out at tx construction time), they are called together 05:25:31 So it's debatable imo that it's worth weighing here and complicating this part of the contest 05:25:52 We had to do it for helioselene I don't see how that contest could have worked without weighing. ec-divisors seems reasonable not to do so to me 05:26:03 The implementation does reuse the `new`. 05:26:55 An implementation with a 5s new and 1s scalar_mul_divisor beats an implementation with a 0s new and 6s scalar_mul_divisor by 5 seconds. 05:27:25 It isn't a theoretical future optimization of questionable complexity/benefit. 05:27:53 You're welcome not to model it, I'm just noting it. 05:29:27 Did you respond to this and I'm just not understanding how you responded to it? "the only time we call the functions in a place where the divisor can't be pre-calculated / cached (when re-calculating the last pseudo out at tx construction time), they are called together" 05:29:42 am I misreading the code? 05:32:41 or you just ignored it sounds like 05:36:03 I wasn't ignoring you. I just failed to get what relevant point you were making. 05:36:31 Would you mind restating it on your end? 05:37:13 Oh. It only just clicked for me. Sorry. 05:37:49 K, yeah, I just disagree with you. You're right this can be part of the precomputation/cache but time for cache population should still be minimized. 05:38:06 The fact there's a literal performance benefit here, as I restated, means it should be modeled if we care to be accurate. 05:38:18 It's trivial enough I want insist we're accurate but this is a real-world part of the prover. 05:42:02 I accept your point. The point I'm raising is that it's tricky to weight it as part of the competition correctly, because there is a point in the implementation where both are called together in a way that is more expensive than other times (i.e. it's not as simple as 11/12 because 1/1 of those times is significantly more important than the others) 05:42:33 Ah 05:42:45 We can add a proper balance proof and make all of these eligible for preprocessing. 05:43:16 That also resolves the fact our current input tuples aren't zero-knowledge as learning n-1 causes you to learn n. 05:43:18 :P 05:44:03 On a more legitimate note, feel free to not weight it then. I do hear you 05:44:54 noice 15:15:46 Taking for granted that there is essentially zero willpower to commit development resources to an OSPEAD response, I want to restate the simplest possible proposal: Update the GAMMA_SHAPE and GAMMA_SCALE values in wallet2.cpp for the next release. 15:16:34 Regarding concerns about low adoption; this is something that can be somewhat controlled. A public notice effort can be undertaken, and if extremely low adoption is encountered it could potentially be compensated by creating a small number of transactions on mainnet. Targeting 10% of present transaction volume, this would require a maximum of ~42000 transactions over the course of 15:16:36 2 weeks to provide a grace period. This would be trivial for the community to perform in aggregate. The timing does not have to be perfect, only reasonable. 15:17:06 How many characters of an address do you need to verify to be reasonably sure you're sending or receiving to the right address? 15:58:09 so say we do release updated gammas in the reference wallet, what would the anonymity puddle be? You'd just be able to tell someone is using the new wallet software, right? Presumably, their real spend is better "hidden" in the decoys. 15:59:20 compared to the old wallet with badgamma. So old wallet users would be in the same situation they are already in. And new wallet users would, in theory, be better hidden ? 16:35:11 Not necessarily, because it would be easier to guess the new wallet users' real spend when they are spending change. I wrote a research note on this. The research note lacks analysis of the classification of decoy selection algorithms, however: https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf 16:39:13 sgp_ veridise funds sent 16:39:41 blargh. So ..... we just have the wallet pick randomly between newgamma and oldgamma 16:51:29 received 16:53:10 Rucknium: I don't have the time to update monero-wallet with local tree building and it'll continue to use a DSA w.r.t. the node connected to. I also assume I don't have time to implement OSPEAD. Would I be able to bother you for gamma suggestions? 16:54:02 It's already assumed a node can fingerprint monero-wallet and this would be done with the FCMP HF so you don't have puddles along patch versions. 16:54:08 kayabanerve: Certainly. That's what I'm here for. I'm also learning a bit of Rust. I can try to write tests 16:55:33 If the answer is still that it doesn't make sense, or if that's too much time from you, completely heard. I just found the idea interesting and think it would fit my specific use-caae of having no time to implement better solutions. 16:57:09 A new gamma would actually just be this one line, with a config var for if to use the updated curve or not: https://github.com/serai-dex/serai/blob/dc1b8dfccd68b7c2eb4359a1e37b55ce5e4453b5/networks/monero/wallet/src/decoys.rs#L102 16:58:19 Please note monero-wallet already abstracts the decoy fetching process. as wallet2 will locally build trees, monero-wallet supports local ring databases today (avoiding any node queries) *if* someone built that extensions. I'll probably do the same re: the tree but only actually implement a solution which asks a node using a gamma distribution. 16:58:38 Others would need to build an OSPEAD-based solution/a locally built tree. 16:59:18 The complication right now is that the new suggested parameters for the Gamma distribution start the Gamma distribution at the first spendable output (after the 10 block lock). It doesn't start it at chain tip and then re-allocate the portion of the distribution that is unspendbale to the recent_outputs region, like the 2021 adjustment to the DSA did. To fix that... 17:00:04 And if I only edit that single line for whatever improvement I can milk out of that? :p 17:00:47 To fix that, the 2021 changes could be reverted in the wallet2 C++ codebase (and changed in the monero-wallet Rust codebase). _Or_ a distribution that _does_ do that re-allocation could be fitted. I mean, I could r-do the fitting procedure. 17:01:06 re-do* 17:03:01 As I said, I'll modularize it when the time comes. I can just do the existing gamma as example/the 'included' solution and you'd be welcome to either PR to it or build an alternative entirely (OSPEAD) if you have the time and that degree of time and interest :) 17:11:40 Sounds good to me 18:05:04 Pinging Cuprate folk (boog900 et al), when you guys eventually get to tree building for sync, I encourage building the logic in a way that could be reusable for clients / monero-wallet. That should make it easier to get local tree building implemented, although it's still a decent lift beyond that 18:20:33 sure will keep it in mind. 19:01:01 SyntheticBird proud 19:06:01 *You'll become a crab and you'll be happy* 19:53:47 jeffro256: Here's plots with that data plotted: https://gist.github.com/Rucknium/f7f9374fc95f16844b674f0895b335ca 19:54:41 kayabanerve: I added a point in the README for ec-divisors scoring saying between 2 submissions that improve the benchmark equally, the one that does so via a slow new and fast scalar_mul_divisor is the stronger submission so contestants have incentive to explore that direction: https://github.com/j-berman/fcmp-plus-plus-optimization-competition/tree/main/ec-divisors-contest#scoring 19:56:16 You can see that the empirical ring distribution is only a little higher than the decoy distribution in the early part of the distribution. But that's all it takes. Rings are 1 part real spend and 15 parts decoy, of course. A small difference between the empirical ring distribution and the decoy distribution means that the real spend distribution is much different from the decoy distribution. 19:58:24 The ring distribution doesn't have as much of a clear "cliff" at 30 minutes as the decoy distribution (that's the end of the recent_spend_windows. AFAIK, that's because the actual cliff moved around a lot during the two years of data because blocks were different sizes and the number of txs/second changes the distribution with respect to output index age. 20:04:38 You can see the decoy distribution (red line) move during the 2024 spam, actually (ISO weeks 2024-09 to 2024-13): 20:04:38 https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/real-spend-visualization.html#pmf-log-y-axis 20:04:59 Just the two frames here: 20:05:00 https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/images/real-spend-pmf-by-week-y-log79.png 20:05:02 https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/images/real-spend-pmf-by-week-y-log83.png