<j​berman:monero.social> Commented my rationale supporting both FCMP++ research proposals in advance of tomorrow's MRL meeting: monero-project/meta #1119#issuecomment-2516057549

Brandon Goodell's GBP security review cc jberman kayabanerve repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_27508

<r​ucknium:monero.social> MRL meeting in this room in one and half hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1119

<r​ucknium:monero.social> 1) Greetings

<j​effro256:monero.social> Howdy

<a​rticmine:monero.social> Hi

<j​berman:monero.social> *waves*

Hello

<v​tnerd:monero.social> hi

<c​haser:monero.social> hello

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<v​tnerd:monero.social> I’ve got to fix a functional test in my monerod patches, its a pain tracking it down for some reason

<r​ucknium:monero.social> me: Suggested spy node ban list community communication plan: gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88 boog900 . HackerOne report.

<j​effro256:monero.social> Me: testing and improving the Carrot code

<j​berman:monero.social> me: wrapping up FCMP++ wallet sync starting from arbitrary restore height (it's working as expected), then planning to move over to FCMP++ proof construction over the FFI

<o​frnxmr:monero.social> Not me, but i hope that those MAX_INPUT tests check 64+ inputs

<j​berman:monero.social> I also commented my +1 on Gooddell's GPB review linked above by @plowsof, and provided more detailed rationale in support of moving forward with Cypher Stack to review Veridise's work on logarithmic derivatives in divisors, and to move forward with Veridise on R1CS proving

Thanks jberman

<r​ucknium:monero.social> 3) Carrot audit/review: github.com/cypherstack/carrot-audit…ses/download/final/Carrot-final.pdf

<r​ucknium:monero.social> jeffro256: Could you give a summary and maybe TODO list that came out of this audit/review?

<j​effro256:monero.social> The review went well with no real crypto issues , I just need to clarify some portions of the spec

<j​effro256:monero.social> Also there were a couple typos

<j​effro256:monero.social> But overall I'm happy with how it went

<j​effro256:monero.social> One change that Kayaba brought up that would actually change the crypto is doing switch commitments

<r​ucknium:monero.social> Doesn't that require a lot of post-quantum R&D?

<j​effro256:monero.social> Not really if we're scoping it to just commitments they're pretty well understood

<j​effro256:monero.social> The hard part is getting some PQ security out of the onetime outputs and key images

<j​effro256:monero.social> But that part can be done later

What would that type of commitments improve?

<j​effro256:monero.social> Amount commitment blinding factors are transmitted as part of the sender-receiver protocol and thus need to be decided beforehand

<j​effro256:monero.social> Rbrunner: A switch commitment allows for a commitment to be perfectly blinding and computationally binding until it "switches" to perfectly binding

<j​effro256:monero.social> Well not really "perfectly", but still computationally binding against a quantum computer