Hi

tevador: I think we could get forward-secrecy for membership proofs by adding G-modifiers to K_1 and Ko just like with X and U. The DLP-solver would be able to figure out the G component `t_k + Hn(q) + k^j_g` by looking at a composition proof (and the X and U components), but wouldn't be able to figure out `t_k` in order to compute the original enote's onetime address.

UkoeHB: I think that would still leak the key paste.debian.net/plainh/6ef69852

Largely irrelevant to monero, since we only perform this check on key images, yet since we don't have consensus on promoting to Ristretto and bypassing this issue entirely, it is sightly helpful.

tevador: you can solve that system for any arbitrary Ko

you will get different t_k, k_g values for each Ko, with no way to verify which pair is real

The original enote author can figure it out if they cached the enote construction details*

UkoeHB: In general, 5 equations with 5 unknowns cannot have arbitrary solutions, but in this case you are right because eqn. 2 is a linear combination of the other 4 equations. So this seems to be the way to get perfect secrecy.

This also means that the non-binding key image construction in Seraphis is a strong point because double spending cannot occur retroactively, while deanonymization can.

meeting 2hr

meeting time monero-project/meta #731

1. greetings

hello

Hey

Hi

Hi

Hi

hello

Hello

Hello.

2. updates, what has everyone been working on?

Hi

I'm still scanning the blockchain using some rust tools and learning more about seraphis. I will be collecting a todo list this month so I can start contributing from October on...

me: finished up my vacation, worked on some jamtis updates for better forward secrecy vs an efficient DLP solver; this coming week I plan to finally start updating the seraphis tx protocol so it can spend legacy enotes

OSPEAD. I think I will finish it next week. I know this is becoming a Zeno's Paradox :P

It's about 70 pages right now with all tables, charts, and references included.

I'm wondering if tevador wants to be on the OSPEAD review panel. I want to give the panel 1-1.5 months to review it. I will be able to release some of it publicly immediately though.

Worked on release prep (collab'd with koe to fix multisig seed restore, restoring from encrypted seed + finalizing/reviewing other PR's). Also drafted an email to engage in discussion with Cypher Stack to work on various tasks and discussed with UkoeHB . Will share more about that later in discussion

I did some preliminary post-quantum research of Seraphis, which resulted in a few changes to the addressing scheme that improve forward secrecy. A draft of other post-quantum mitigations can be found here: gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a

I’ve been answering questions on reddit related to my MAGIC report. SGP and I will be posting a Q&A at some point soon answering some common questions.

jberman: Does one of those potential tasks include writing math proofs for Seraphis? I have been thinking that CypherStack could be good for that. And dangerousfreedom could follow up with them.

Yep, agree on that

3. discussion

Maybe some of these funds could be re-purposed? ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html

xmrack: What do you think is actionable about your research?

Rucknium[m]: I would be happy to check and I could quickly build some accurate (but slow) Python tools for prototyping and documenting

The 4 tasks I initially included in the draft: (1) security proofs for multisig, (2) reviewing Seraphis and Jamtis, (3) exploring trustless zk-SNARKs in Monero, and (4) vetting bulletproofs++

I initially felt that multisig should be first priority in discussions because it can impact user funds today

UkoeHB responded with a better fleshed out email (makes it clearer exactly what would be useful in pushing Seraphis and Jamtis forwards -- including security proofs for Seraphis), that also shifts prioritizing multisig downwards for the following reason:

jberman: Agree on multisig as 1st priority. That is quite the hefty research agenda :)

> I am concerned that a lot of work spent on current Monero multisig would just go to waste once Seraphis goes live. I'd personally be ok with leaving it experimental until wallet2 is deprecated. Note that the above list constitutes a TON of work that needs to be done before Seraphis goes live. Seraphis multisig on its own is a doozy if we want to go all the way.

I am leaning towards this conclusion as well. To support this conclusion further, yesterday I found that encrypted multisig seeds have been un-recoverable for the past ~4 years because of a bug that has gone unreported until issue 8537. To me this suggests multisig has seen very little use, and as such, I think it's reasonable to prioritize looking forwards to land on the future safe form of multisig

Well, should the interested parties in the ecosystem take the lead on multisig strengthening then?

Hmmm, strange, I think I recovered such a wallet from a seed that RINO provided in their "recovery document"

I agree that Seraphis should be the priority.

Does it fail only in certain cases?

rbrunner: encrypted with a seed passphrase?

That, no.

Rucknium: My research found that training various ML/DL models on past transaction information can lead to a slight performance increase over random guessing. Notably one of the highest feature importances was surrounding the tx_extra field. This is likely due to the non-uniform constraints placed on it, as we’ve discussed in the past.

Temporal and positional relationships of transactions and blocks had a much lower feature importance to the models. Overall, there was less information leakage strictly on-chain than I initially anticipated, which is good news!

Ah, I just overlooked the word "encrypted" ...

rbrunner: that's the type that's been unrecoverable. An edge case, but still lends strength I think to the view that it's sensible to prioritize looking forwards

Well, I suspect as well that multisig sees very little use, from the non-use of my MMS. Of course not everybody will like that, but with many multisig users some should

Nobody told me yet that is does not work with the latest version of PyBitmessage ...

"Seraphis multisig on its own is a doozy if we want to go all the way." I don't understand the English word "doozy" in this context. Easy? Simple? Good?

xmrack: I have considered a multivariate decoy selection algorithm. Right now, it's purely univariate on output age. I think your research suggests that multivariate might not be necessary since the other variables seem to not leak much exploitable information. Of course, this was an artificial dataset.

I'm not sure if any pre-existing multisig wallets actually work: monero-project/monero #8329#issuecomment-1216946632

I only heard of one complaint

rbrunner: it's missing UkoeHB 's context which details a fairly large amount of work involved of formalizing security proofs and vetting multisig as implemented in Seraphis

So it's the opposite - it will be hard until production-ready?

So better safe our powder for that big work?

Rucknium: I agree, what were the other variables you were considering?

xmrack: Really anything that is not uniform across transactions.

rbrunner: seraphis multisig includes both legacy and seraphis multisig signing

in addition to account migrations

Still from a workload and overall efficiency perspective focusing on Seraphis for multi sig is the way to proceed

I suggested starting with BP++ paper review + proof-of-concept, since at least that can be implemented in ringct if seraphis is taking too long

Did we hear anything more from ooo about their BP++ implementation, or is it still only those timing results?

selsta:

not yet

Ok, that's a known unknown then :)

What are the gains with BP++ vs BP+?

ArticMine[m]: monero-project/research-lab #101

Rucknium: is there a number of de-anonymized mainnet transactions that could be sourced in a federated manner to represent the population? Would this allow you to represent the population and include multiple variables to the new DSA?

the batched verification in that test is -10%, with tx construction -72%, tx size -256 bytes

There is the very old Moser et al. (2018) de-anoned data. If we are brainstorming, we could do some sort of cutting-edge differential privacy-compliant technique where people run some sort of estimator or algorithm on their own txs and then send us the results only, protecting privacy somehow.

Yea I was thinking something along the lines of the latter

is the BP++ test source code available for review?

tevador: no, and I'm skeptical it ever will be

I'm just taking the results at face value as reinforcing the author's perf predictions.

UkoeHB: Thanks

Regarding multisig: The idea of throwing every available hour from now on into the direction of Seraphis sounds good to me.

Of course there are certain residual risks, lacking proofs and all, but should not be too risky

(with current multisig)

multisig still needs PRs 8329 and 8203 at least... then I can use my seraphis lib to do an escrowed exchange demo (my last planned project for monero post-seraphis)

How would be pay Cypher Stack? Through CCS?

By the way, I include some ring size 128 analysis in OSPEAD. So maybe OSPEAD will be Seraphis-ready :)

with BP++ I think we might be able to justify ring size 256

if it pans out

Ring 256 would be great

Great to hear. I'll keep my analysis at 128 for now so that I don't sink even more time into it.

Pinging vtnerd to see if he'd be available to review 8329 and 8203 to completion. I'll look into them in a few days if not

8203 needs to rebase onto 8329

W.r.t. to Cypher Stack, planning to go with koe's suggestions and engage with them with the following priorities in order: bp++, Seraphis core proof modeling, Jamtis design review, Seraphis multisig

On trustless zk-SNARKs, I'm waiting to hear from kayabanerve to get a better idea how best to proceed there. I would personally like to see research into zk-SNARKs pushed forward with high priority, so will probably bring it up in discussions with Cypher Stack anyway too

I thought multisig securtiy proofs would be applicable to seraphis (with some changes) ?

I'm confused what the plan is now with multisig

I'm personally fine with leaving the current stuff experimental until wallet2 and ringct are deprecated.

putting more resources toward current multisig may end up delaying seraphis

I don't see how that would be the case if we fund someone external for it

I just know that we have multiple people in the ecosystem who plan to use multisig soon and not in a couple years

I will

external people are also in limited supply

I see trustless zk-SNARKS as a possibility after Seraphis; however we must keep in mind that we are dealing with finite anonymity sets in any case, when comparing to 256 Seraphis plus OPSREAD

The gain may reach dining returns

ArticMine[m]: the goal would be using a full anonymity set for seraphis membership proofs (a straight upgrade instead of tx protocol replacement)

Diminishing

I think people who want to use Monero multisig now should replace "experimental" with something like "lacks formal proof / verification" and then see whether that is ok with their risk tolerance

rbrunner: well just a matter until someone exploits it

After all, the code *was* reviewed.

It's a thorny issue, because it's basically opinion versus opinion, but I for one give some trust to our own reviews by quite competent people. That was not nothing, so to say.

UkoeHB: Then it definitely becomes something to look at after the initial Seraphis

It can only be a matter of time until someone exploits if there is an exploit to be found - which I don't see as certain.

ok we are at the end of the hour so I'll call it; thanks for attending everyone

Would an exploit of multisig be detectable on the blockchain data?

ArticMine[m]: Seraphis and Jamtis present major changes to Monero's core structural architecture. It would be very unfortunate if we found that a whole tier in Jamtis for example had to be eliminated in order to implement zk-SNARKs, or that we need a new address structure, etc. Research into zk-SNARKs moving in parallel would lend us greater confidence into the new foundational structural brought by Seraphis/Jamtis

I don't think we should assume that if it gets exploited, somehow we will be notified.

Rucknium[m]: doubtful

<jberman[m]> "I am leaning towards this..." <- I also think selsta makes a good point. My view here that multisig use today seems low was irrelevant considering there are new use cases on the immediate horizon for it where stakes will be high (Haveno, RINO). Going to think on it more

the thought of this 300k donation going to a domain redirect instead of security proofs is frustrating, especially when we know there are still likely issue(s) remaining

Ah, yes, that story. Something new already there? Probably not ...

That believe in the power of domain names ... I will probably never really understand that.

That money would be much better spent on Seraphis.

jberman: But if the research found that zk-SNARKS would break part of Seraphis would you consider this a strong negative against Seraphis? I am not against the research, I just want to see the implications

Basically *anything* else than buying monero.com if you ask me.

One of the pros of Seraphis is a modular tx structure that would hopefully allow a drop-in full chain membership proof, trustless zk-SNARKs seemingly the most promising option today. So it would be very nice to evaluate that pro

jberman: Yes I do agree evaluating that pro is a plus

if it doesn't work with seraphis, that just means you need a whole new tx protocol to support it - you'll be starting at zero with or without seraphis

I hope people are aware that right now the Zcash chain is being flooded with trustless zk-SNARK outputs that have made many wallets unusuable due to sync times. Hopefully a solution can be found if Monero were to use the technology.

don't they have a solution that only some wallets implemented?

Do they hide the tx fee?

In ZCash

That reminds me... the argument for one byte view tag was: it slashes fully scanned outputs by 99.5%, so an extra 0.5% is pointless.

Warp Sync helps a bit. SOme people can't even sync the chain itself. And now Ywallet is just excluding txs it considers spam (>20 outputs) from scanning, which works until the spammer changes tactics or gets a slightly bigger budget.

However, this is not the right way to see it. Adding a second byte slashes the remaining time by 99.5% also, and if we'd get spammed, that remaining time would be large in the first place.

No, Zcash does not hide fees

moneromooo: for seraphis we are adding another ~zero-cost 2-byte (tentative) filter after the view tag

It looks like seraphis fixes an ungodly number of things...

s/fixes/improves/

if bitcoin was the prototype and cn/ringct were experimental designs - seraphis is the full release :)

In my view ZCash has very serious problems with scaling and spam that have little to do with the specific privacy tech.

These problems were inherited from Bitcoin, and privacy has only made them worse

Yes, Zcash overlooked many critical scaling problems that are finally having consequences. A fixed but large-ish block size and a low minrelayfee set as per tx, not per kb.

Instead of Monero trying to come up with an exploit proof 2 out of 3 multisig protocol for Haveno and RINO, couldn't they work with 3 out 3 multisigs?

Right to me at first glance it doesn't look like zk-SNARKs are the insurmountable cause of their issues there, but better/more informed answers are definitely warranted

Oh, and I think there is no particular limit on number of outputs per tx

So it's their wallets that are having trouble, not daemons ?

s/daemon/node/

Wallets don't have the same "realtime-ish" needs.

Think of stripping away all of Monero's defenses against spam

Allow unlimited number of outputs with no increase in fees to permit a verification attack

No cost to increase the blocksize

It's mostly wallet scanning, but some users are reporting node sync issues too

Anyway, we have Seraphis verification benchmarks, but AFAIK no benchmark comparisons with trustless zk-SNARKS. Just another thing to put on the zk-SNARK research TODO list.

I always thought zcash was better that Monero at verification performance for some reason. That's interesting. Or... worrying.

Their new shielded tx version is quite different.

they are also missing many basic features like restoring from seed

The importance of fees is often underestimated. More than a year ago, I warned BEAM that their relay fees were laughably low, on the order of $0.5 per 10GB of spam. I don't think they cared much.

It is even more critical with privacy because one cannot censor spam

ZCash is having issues with transaction rates including t transactions way below current Monero transaction rates.

One would expect more for their $xx million dev tax money.

One can have very serious spam issues even on transparent chains. Just take a look at the wild gyrations in blocksize in Bitcoin SV

Also no amount of millions of USD can fix the Bitcoin security / scaling / spam issues, without dealing with the underlying causes starting with the 21 million BTC limit

ZCash's issues can ultimately be traced back to Bitcoins issues

$$money wasted on devs with no integrity...