meeting 2hr

meeting time monero-project/meta #727

1. greetings

hello

Hi

Hi

Hello

looks like a low-turnout day, might be a short meeting

2. updates, what's everyone working on?

I’m finishing up my final report for the magic grant which will be released Sept 1.

ooo123ooo1234567 posted an update on bulletproofs++ verification speed and it looks really promising for monero: monero-project/research-lab #101

me: closed my previous ccs and opened a new one repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/338; started integrating tevador's mx25519 library into seraphis_lib to hopefully speed up the find-received scanning step (should have a performance test ready next week)

though I don't know what his plans are with the code now

OSPEAD work. Some research into possible methods to probabilistically classify on-chain transactions by their decoy selection algorithms, which would decrease effective transaction uniformity.

selsta: an almost 3x speedup seems too good to be true, looking forward to the code if/when it becomes available

UkoeHB: what part of the transaction verification is the bulletproof part? how would that translate to transaction verification?

iirc it's around half of the cost

me: I've been focused on wrapping up hard fork issues, atm specifically on more cleanly handling the case when an updated client connects to an older daemon and vice versa

I said last week I'd have a plan for moving forward with multisig to get it out of experimental but have been prioritizing the above. Will share my thoughts on it

ah looks like the batched verification isn't much faster in that test run

the speedup in proof construction would be a big win, making bps is really slow

3. discussion, anything to discuss?

jberman[m]: ?

Preliminary plan of action on moving multisig forward:

Open discussion with veorq with UkoeHB involved if willing, explain we'd like to get security proofs written for multisig and that our goal is to arrive at a well-vetted and safe multisig implementation that we are confident is no longer experimental. Will work together with veorq/koe to try to help explain the code so the security proofs can cover the entire multisig protocol

In that discussion, we'd discuss cost and time to completion estimates. Once we have a working framework established that is mutually agreeable toward achieving the above objective, would then look to funding

Sounds good to me

works for me

would these security proofs also apply to seraphis multisig later?

not directly, because there is a new proof structure

the new proof is basically a schnorr signature though, so existing multisig security proofs should be easy enough to adapt

ok, so we don't start with 0 again

So all multisig wallets need to get "dissolved" before the Seraphis hardfork?

rbrunner: no, I have a migration strategy

Oh, surprising

multisig groups just need to do one extra ceremony to migrate

jberman, at the last meeting you said "I think a change to the algo that would result in identifiable pools without a HF needs a very high bar to pass" I think it's possible to reduce the question to direct probability calculations, i.e. probability of correct guess of the real spend with current DSA vs. probability of guessing the real spend based on a probabilistic classification of the DSA that a given transaction is using in

a partial migration scenario.

Is such a comparison what you had in mind for the criterion?

rbrunner: github.com/UkoeHB/monero/blob/c822c…it_tests/seraphis_multisig.cpp#L144 this is account migration

Thanks, interesting

oh, and you'd need to update legacy multisig accounts so they can do aggregation-style signing on legacy enotes

that's on my TODO

I have found a few candidate methods to classify on-chain rings by their DSA. xmrack may have additional ideas.

If we have a high proportion of rings where the probability it's constructed by old DSA diverges largely from the new DSA, that would be a no-go imo

No-go until a hard fork, I assume?

right. unless we're certain there is some glaring issue that must be fixed

There is a glaring issue. The question you pose, which you're right to pose, is if the cure is worse than the disease. Anyway, I think it's probably possible to get a clear, fairly precise answer on that.

sgtm

I'm probably going to need more funding for that analysis though 😅

are there any other topics anyone would like to discuss? questions?

ok I'll call it here, thanks for attending everyone

selsta: there aren't many google hits for bp++, do you think we should hit up bunz's team and possibly some others to review the paper?

We could also ask the paper's author if he has submitted it for publication anywhere.

it would be great if ooo123ooo1234567 could clarify his plans on how to continue with bulletproofs++ now, he did say he spent time on checking security but i don't know what that entails

kayabanerve: Want to email the BP++ author and ask if it is under review anywhere?

otherwise we can either try to contact the paper author or like you suggested someone who was involved with Bulletproofs

quite sure the author of B++ works for spacex now

so no idea how available he is

How did you come across that info?

linkedin

i was curious what their background was

but that was a couple months ago could be outdated at this point

I will contact the bp++ author

UkoeHB: is batched verification the only thing relevant for us?

apart from generating proofs

Thanks. I didn't want to do it since I don't understand cryptography

selsta: also 256 byte smaller proofs

i meant solely regarding verification

either way it is a nice upgrade with basically everything improved

Does anyone know Sarang’s opinion on the BP++ paper?

he has not made any public comments on it that I'm aware of

UkoeHB: I took the liberty to post this: old.reddit.com/r/Monero/comments/ww…bute_to_moneros_future_support_koes

thanks rbrunner

Welcome. Thank you for you perseverance and still forging on :)

BP++ author says he's working on conference submission(s). He would like to see the BP++ code if possible

Good to hear :)