00:20:06 We wrote a patch (for wallet2) to compute the corresponding tx keys for a given transaction for all outputs. Could anyone who is well versed on the C++ codebase look over this code? 00:20:07 https://github.com/eigenwallet/core/pull/629/files#diff-c9d5ca4520dae76f94a76af80663cb9201bd532c7b830a2700999b7ed990ce89 00:20:09 I'm offering 0.3 XMR for any bug found in that code (I know it's not much) 00:20:11 I'm referencing a discussion about tx keys and transfer proofs from a few days ago. Not sure if the quotation is visible on IRC. 00:23:06 The reply is not visible on irc 00:27:18 I'm referencing the discussion from here: https://libera.monerologs.net/monero-dev/20251015#c599409-c599581 13:46:13 Hi guys, was reading Seraphis, and looking at the transaction, it follows this format: 13:46:13 Inputs: 13:46:14 – Enote images 13:46:14 – Membership proofs 13:46:15 – Ownership and unspentness proofs 13:46:15 Outputs: 13:46:16 – Enotes 13:46:16 – Range proofs 13:46:17 Others: 13:46:17 - Balance proof 13:46:18 Was wondering, why is there no need for a proof that the output enotes was "signed"/"approved" by the spender? Like how does it prevent a malicious guy from forging/modifying the output enotes and send it to himself? 13:48:15 Someone with the viewing key of the input enotes can easily forge a valid balance proof along with the tampered output enotes, no? 13:50:47 Btw this was the paper I was reading: https://github.com/UkoeHB/Seraphis/blob/master/seraphis/Seraphis-0-0-18.pdf 13:56:10 "unspentness proofs" are the key words 14:00:42 Doesnt unspentness only proves the input enotes were not spent before? Does not prove that the output enotes are to the target recipients? 14:06:32 Ah I see it in section 3.7, the outputs are witnesses to the ownership & unspentness proof to achieve binding 14:12:56 also, Monero is not moving to Seraphis 14:17:32 Oh wot, I was told yesterday it was moving to Seraphis '=D 14:19:49 Maybe consider leaving out ring signatures altogether, as we are on the way to stop to use those with a hardfork in 1 year or maybe a bit less? The "kid on the block" is FCMP++. 14:51:54 FCMP++ is not seraphis https://www.getmonero.org/2024/04/27/fcmps.html 16:50:19 .merge+ 10172 10156 10153 10123 10083 16:50:19 Added 18:53:53 done 19:10:34 In the threadpool.cpp, has anyone tried if workstealing with a chase-lev dequeue or a bwos queue results in any performance benefits? 19:10:35 Are there any standardized benchmarks i can run when testing such a thing? 19:10:37 Also, Does someone have a flake.nix for the monero project? 19:14:39 https://github.com/monero-project/monero/pull/9768#issuecomment-2636444224 19:14:50 Related? 19:20:06 Yeah thats related. 19:20:07 Finally something i am good at and can maybe contribute 19:36:32 as far as I can see, threadpool in monerod uses a single global queue for all threads. If it doesn't spend more than 1% waiting for that lock, you won't get much improvement with more advanced scheduling algorithms 19:37:24 need to run it with profiler 19:48:00 Yeah we're much likelier to get way, way more performance benefit by doing ZK batching / parallelization across multiple blocks at a time. IMO, those should be pursued first before making the threadpool significantly more complex, unless it can be demonstrated that the threadpool queue is a blocker