<b​inarybaron:matrix.org> 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?

<b​inarybaron:matrix.org> eigenwallet/core #629/files#diff-c9d5ca4520dae76f94a76af80663cb9201bd532c7b830a2700999b7ed990ce89

<b​inarybaron:matrix.org> I'm offering 0.3 XMR for any bug found in that code (I know it's not much)

<b​inarybaron:matrix.org> 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.

<o​frnxmr:xmr.mx> The reply is not visible on irc

<b​inarybaron:matrix.org> I'm referencing the discussion from here: libera.monerologs.net/monero-dev/20251015#c599409-c599581

Hi guys, was reading Seraphis, and looking at the transaction, it follows this format:

Inputs:

– Enote images

– Membership proofs

– Ownership and unspentness proofs

Outputs:

– Enotes

– Range proofs

Others:

- Balance proof

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?

Someone with the viewing key of the input enotes can easily forge a valid balance proof along with the tampered output enotes, no?

Btw this was the paper I was reading: github.com/UkoeHB/Seraphis/blob/master/seraphis/Seraphis-0-0-18.pdf

"unspentness proofs" are the key words

Doesnt unspentness only proves the input enotes were not spent before? Does not prove that the output enotes are to the target recipients?

Ah I see it in section 3.7, the outputs are witnesses to the ownership & unspentness proof to achieve binding

also, Monero is not moving to Seraphis

Oh wot, I was told yesterday it was moving to Seraphis '=D

<r​brunner7:monero.social> 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++.

FCMP++ is not seraphis getmonero.org/2024/04/27/fcmps.html

.merge+ 10172 10156 10153 10123 10083

Added

done

<a​tomfried:matrix.org> In the threadpool.cpp, has anyone tried if workstealing with a chase-lev dequeue or a bwos queue results in any performance benefits?

<a​tomfried:matrix.org> Are there any standardized benchmarks i can run when testing such a thing?

<a​tomfried:matrix.org> Also, Does someone have a flake.nix for the monero project?

<o​frnxmr:xmr.mx> monero-project/monero #9768#issuecomment-2636444224

<o​frnxmr:xmr.mx> Related?

<a​tomfried:matrix.org> Yeah thats related.

<a​tomfried:matrix.org> Finally something i am good at and can maybe contribute

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

need to run it with profiler

<j​effro256:monero.social> 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