01:29:12 <JungleCreep[m]> Hi
01:31:41 <UkoeHB> 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.
08:48:37 <tevador> UkoeHB: I think that would still leak the key https://paste.debian.net/plainh/6ef69852
10:36:45 <kayabanerve[m]> https://eprint.iacr.org/2022/1164
10:36:46 <kayabanerve[m]> 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.
12:03:13 <UkoeHB> tevador: you can solve that system for any arbitrary Ko
12:07:00 <UkoeHB> you will get different t_k, k_g values for each Ko, with no way to verify which pair is real
12:15:31 <UkoeHB> The original enote author can figure it out if they cached the enote construction details*
12:57:31 <tevador> 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.
13:00:21 <tevador> 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.
14:58:04 <UkoeHB> meeting 2hr
17:00:12 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/731
17:00:20 <UkoeHB> 1. greetings
17:00:21 <UkoeHB> hello
17:00:35 <xmrack[m]> Hey
17:00:40 <rbrunner> Hi
17:00:40 <Rucknium[m]> Hi
17:00:40 <tevador> Hi
17:00:45 <jberman[m]> hello
17:00:54 <dangerousfreedom> Hello
17:01:49 <one-horse-wagon[> Hello.
17:02:51 <UkoeHB> 2. updates, what has everyone been working on?
17:03:16 <ArticMine[m]> Hi
17:04:18 <dangerousfreedom> 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...
17:04:41 <UkoeHB> 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
17:04:55 <Rucknium[m]> OSPEAD. I think I will finish it next week. I know this is becoming a Zeno's Paradox :P
17:04:55 <Rucknium[m]> It's about 70 pages right now with all tables, charts, and references included.
17:05:54 <Rucknium[m]> 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.
17:06:24 <jberman[m]> 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
17:06:51 <tevador> 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: https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a
17:07:17 <xmrack[m]> 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. 
17:08:05 <Rucknium[m]> 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.
17:09:49 <jberman[m]> Yep, agree on that
17:10:31 <UkoeHB> 3. discussion
17:11:00 <Rucknium[m]> Maybe some of these funds could be re-purposed? https://ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html
17:11:49 <Rucknium[m]> xmrack: What do you think is actionable about your research?
17:12:34 <dangerousfreedom> Rucknium[m]: I would be happy to check and I could quickly build some accurate (but slow) Python tools for prototyping and documenting
17:14:33 <jberman[m]> 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++
17:14:46 <jberman[m]> I initially felt that multisig should be first priority in discussions because it can impact user funds today
17:15:34 <jberman[m]> 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:
17:15:41 <Rucknium[m]> jberman: Agree on multisig as 1st priority. That is quite the hefty research agenda :)
17:15:50 <jberman[m]> > 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.
17:16:17 <jberman[m]> 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
17:17:02 <Rucknium[m]> Well, should the interested parties in the ecosystem take the lead on multisig strengthening then?
17:17:20 <rbrunner> Hmmm, strange, I think I recovered such a wallet from a seed that RINO provided in their "recovery document"
17:17:42 <tevador> I agree that Seraphis should be the priority.
17:17:56 <rbrunner> Does it fail only in certain cases?
17:17:57 <jberman[m]> rbrunner: encrypted with a seed passphrase?
17:18:06 <rbrunner> That, no.
17:18:11 <xmrack[m]> 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. 
17:18:11 <xmrack[m]> 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!
17:19:26 <rbrunner> Ah, I just overlooked the word "encrypted" ...
17:19:32 <jberman[m]> 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
17:20:20 <rbrunner> 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
17:21:08 <rbrunner> Nobody told me yet that is does not work with the latest version of PyBitmessage ...
17:21:47 <rbrunner> "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?
17:22:13 <Rucknium[m]> 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.
17:22:28 <UkoeHB> I'm not sure if any pre-existing multisig wallets actually work: https://github.com/monero-project/monero/pull/8329#issuecomment-1216946632
17:22:35 <UkoeHB> I only heard of one complaint
17:23:20 <UkoeHB> https://libera.monerologs.net/monero/20220816#c136742
17:23:33 <jberman[m]> 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
17:24:06 <rbrunner> So it's the opposite - it will be hard until production-ready?
17:24:21 <rbrunner> So better safe our powder for that big work?
17:24:57 <xmrack[m]> Rucknium: I agree, what were the other variables you were considering?
17:25:44 <Rucknium[m]> xmrack: Really anything that is not uniform across transactions.
17:26:04 <UkoeHB> rbrunner: seraphis multisig includes both legacy and seraphis multisig signing
17:26:11 <UkoeHB> in addition to account migrations
17:26:27 <ArticMine[m]> Still from a workload and overall efficiency perspective focusing on Seraphis for multi sig is the way to proceed 
17:27:07 <UkoeHB> 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
17:27:52 <rbrunner> Did we hear anything more from ooo about their BP++ implementation, or is it still only those timing results?
17:28:04 <UkoeHB> selsta: 
17:28:53 <selsta> not yet
17:29:15 <rbrunner> Ok, that's a known unknown then :)
17:29:15 <ArticMine[m]> What are the gains with BP++ vs BP+?
17:29:28 <UkoeHB> ArticMine[m]: https://github.com/monero-project/research-lab/issues/101
17:29:35 <xmrack[m]> 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? 
17:30:32 <UkoeHB> the batched verification in that test is -10%, with tx construction -72%, tx size -256 bytes
17:31:50 <Rucknium[m]> 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.
17:32:34 <xmrack[m]> Yea I was thinking something along the lines of the latter
17:32:44 <tevador> is the BP++ test source code available for review?
17:33:00 <UkoeHB> tevador: no, and I'm skeptical it ever will be
17:33:29 <UkoeHB> I'm just taking the results at face value as reinforcing the author's perf predictions.
17:35:17 <ArticMine[m]> UkoeHB:  Thanks 
17:35:20 <rbrunner> Regarding multisig: The idea of throwing every available hour from now on into the direction of Seraphis sounds good to me.
17:35:42 <rbrunner> Of course there are certain residual risks, lacking proofs and all, but should not be too risky
17:36:14 <rbrunner> (with current multisig)
17:36:55 <UkoeHB> 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)
17:39:25 <rbrunner> How would be pay Cypher Stack? Through CCS?
17:40:10 <Rucknium[m]> By the way, I include some ring size 128 analysis in OSPEAD. So maybe OSPEAD will be Seraphis-ready :)
17:40:31 <UkoeHB> with BP++ I think we might be able to justify ring size 256
17:41:00 <UkoeHB> if it pans out
17:41:44 <ArticMine[m]> Ring 256 would be great 
17:42:04 <Rucknium[m]> Great to hear. I'll keep my analysis at 128 for now so that I don't sink even more time into it.
17:42:12 <jberman[m]> 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
17:42:34 <UkoeHB> 8203 needs to rebase onto 8329
17:44:16 <jberman[m]> 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
17:45:31 <jberman[m]> 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
17:46:17 <selsta> I thought multisig securtiy proofs would be applicable to seraphis (with some changes) ?
17:46:31 <selsta> I'm confused what the plan is now with multisig
17:48:15 <UkoeHB> I'm personally fine with leaving the current stuff experimental until wallet2 and ringct are deprecated.
17:51:39 <UkoeHB> putting more resources toward current multisig may end up delaying seraphis
17:52:06 <selsta> I don't see how that would be the case if we fund someone external for it
17:52:32 <selsta> I just know that we have multiple people in the ecosystem who plan to use multisig soon and not in a couple years
17:53:16 <vtnerd> I will
17:53:35 <UkoeHB> external people are also in limited supply
17:56:02 <ArticMine[m]> 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
17:56:38 <ArticMine[m]> The gain may reach dining returns 
17:56:59 <UkoeHB> ArticMine[m]: the goal would be using a full anonymity set for seraphis membership proofs (a straight upgrade instead of tx protocol replacement)
17:57:05 <ArticMine[m]> Diminishing 
17:57:25 <rbrunner> 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
17:57:41 <selsta> rbrunner: well just a matter until someone exploits it
17:57:43 <rbrunner> After all, the code *was* reviewed.
17:59:10 <rbrunner> 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.
17:59:12 <ArticMine[m]> UkoeHB: Then it definitely becomes something to look at after the initial Seraphis 
18:00:15 <rbrunner> 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.
18:01:13 <UkoeHB> ok we are at the end of the hour so I'll call it; thanks for attending everyone
18:01:45 <Rucknium[m]> Would an exploit of multisig be detectable on the blockchain data?
18:02:25 <jberman[m]> 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
18:02:34 <Rucknium[m]> I don't think we should assume that if it gets exploited, somehow we will be notified.
18:04:05 <UkoeHB> Rucknium[m]: doubtful
18:04:43 <jberman[m]> <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
18:05:34 <selsta> 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
18:06:09 <rbrunner> Ah, yes, that story. Something new already there? Probably not ...
18:06:41 <rbrunner> That believe in the power of domain names ... I will probably never really understand that.
18:06:56 <tevador> That money would be much better spent on Seraphis.
18:07:04 <ArticMine[m]> 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 
18:07:35 <rbrunner> Basically *anything* else than buying monero.com if you ask me.
18:10:34 <jberman[m]> 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
18:13:00 <ArticMine[m]> jberman: Yes I do agree  evaluating that pro is a plus
18:14:17 <UkoeHB> 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
18:14:32 <Rucknium[m]> 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.
18:15:21 <UkoeHB> don't they have a solution that only some wallets implemented?
18:15:45 <UkoeHB> https://forum.zcashcommunity.com/t/warp-sync-a-full-scan-method/39462
18:15:47 <ArticMine[m]> Do they hide the tx fee?
18:15:55 <ArticMine[m]> In ZCash 
18:16:41 <moneromooo> 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.
18:17:16 <Rucknium[m]> 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.
18:17:16 <moneromooo> 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.
18:17:33 <Rucknium[m]> No, Zcash does not hide fees
18:17:51 <UkoeHB> moneromooo: for seraphis we are adding another ~zero-cost 2-byte (tentative) filter after the view tag
18:18:38 <moneromooo> It looks like seraphis fixes an ungodly number of things...
18:18:47 <moneromooo> s/fixes/improves/
18:20:09 <UkoeHB> if bitcoin was the prototype and cn/ringct were experimental designs - seraphis is the full release :)
18:23:04 <ArticMine[m]> In my view ZCash has very serious problems with scaling and spam that have little to do with the specific privacy tech. 
18:23:04 <ArticMine[m]> These problems were inherited from Bitcoin, and privacy has only made them worse
18:25:42 <Rucknium[m]> 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.
18:26:10 <one-horse-wagon[>    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? 
18:26:11 <jberman[m]> 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
18:26:23 <Rucknium[m]> Oh, and I think there is no particular limit on number of outputs per tx
18:31:09 <moneromooo> So it's their wallets that are having trouble, not daemons ?
18:31:49 <moneromooo> s/daemon/node/
18:32:15 <moneromooo> Wallets don't have the same "realtime-ish" needs.
18:32:47 <ArticMine[m]> Think of stripping away all of Monero's defenses against spam
18:34:07 <ArticMine[m]> Allow unlimited number of outputs with no increase in fees to permit a verification attack 
18:34:32 <ArticMine[m]> No cost to increase the blocksize
18:46:46 <Rucknium[m]> It's mostly wallet scanning, but some users are reporting node sync issues too
18:46:48 <Rucknium[m]> https://forum.zcashcommunity.com/t/zcashd-use-to-much-memory-without-any-reasons/42919
18:46:59 <Rucknium[m]> https://forum.zcashcommunity.com/t/zcashd-help/42885
18:48:20 <Rucknium[m]> 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.
18:48:45 <moneromooo> I always thought zcash was better that Monero at verification performance for some reason. That's interesting. Or... worrying.
18:49:36 <Rucknium[m]> Their new shielded tx version is quite different.
18:50:16 <selsta> they are also missing many basic features like restoring from seed
18:52:19 <tevador> 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.
18:53:19 <ArticMine[m]> It is even more critical with privacy because one cannot censor spam
18:55:16 <ArticMine[m]> ZCash is having issues with transaction rates including t transactions way below current Monero transaction rates. 
18:58:06 <tevador> One would expect more for their $xx million dev tax money.
19:00:32 <ArticMine[m]> One can have very serious spam issues even on transparent chains. Just take a look at the wild gyrations in blocksize in Bitcoin SV 
19:04:03 <ArticMine[m]> 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 
19:04:52 <ArticMine[m]> ZCash's issues can ultimately be traced back to Bitcoins issues 
19:07:38 <hyc> $$money wasted on devs with no integrity...