00:17:21

ArticMine: I have often wondered what it would take to set up a super public node whereby your have 500 in connections or a 1000 or more. Thanks for your math as it gives me a few ideas to look at. 13:46:09 kayabanerve: Could you add some links/references to papers to https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86 ? E.g. Generalized Bulletproofs, Eagan's divisor technique, maybe Generalized Schnorr Protocol? Thanks. 15:15:28 I'll try to today. 15:30:11 MRL meeting in this room in 1.5 hours. 15:34:43 Matrix users on the matrix.org Matrix homeserver may have to refresh https://libera.monerologs.net/monero-research-lab a lot to see the conversation here because messages to matrix.org are delayed. We can see messages _from_ users on the matrix.org server with no problems AFAIK. (This message will probably arrive to their client with minutes or hours of latency.) 17:00:28 Meeting time! https://github.com/monero-project/meta/issues/986 17:00:36 1) Greetings 17:01:00 hello 17:01:02 Hi 17:01:03

Hello 17:01:04 Hello everybody! 17:01:10 hello 17:01:14 Hi 17:01:18 Hello hello! 17:01:24 hello 17:01:30 hello 17:01:34 Hi 17:01:47 Heyo 17:02:03 Hello 17:02:10 Hi! 17:03:46 2) Updates. What is everyone working on? 17:04:02 Meeting time? 17:04:08 Matrix is broken 17:04:11 I am here 17:04:49 FCMPs, as expected 17:05:21 me: I posted the preliminary report about the suspected black marble flooding: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf 17:05:53 @rucknium Very good read! 17:06:17 As of 12:00 UTC today, estimated mean effective ring size is back up to 14 (assuming the spam was by an adversary creating black marble outputs): https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/empirical-effective-ring-size.png 17:06:27 me: the asynchronous wallet scanner, ironed out final kinks / started on benchmarking. pushing final changes and marking the PR ready for review today 17:07:25 I am also tracking an anomalous rise in 2nd tier fee transactions. We are over 50% without clear cause in the last 3-4 days: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/share-tx-in-fee-tier-spam-removed.png 17:07:44 @rucknium do you think we see another wave of the attack rn with tx above 50k/day or is it rather organic? 17:08:27 I am working on the scaling and fees. 17:08:27 Now that we have estimates for FCMP transactions weights. I can say that a minimum penalty free zone of 600000 bytes is realistic. Also a 2% growth rate. Minimum fee about 5x to 6x the current 17:08:49 janowitz: I'm not sure. Maybe the increase of 2nd tier fee txs is the suspected spammer changing behavior. Thanks for your questions. 17:09:28 Blocks don't seem as full as last time though 17:09:31 ^ rucknium 17:09:33 At least for now 17:09:51 I also posted a CCS funding proposal to continue this research to help guide decisions on ring member size increases and fees to defend against black marble attacks. Feedback and questions are welcome :) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/439 17:10:23 Is it not superseded by FCMPs /s 17:10:34 Yes, block/txpool are not full, which means that the auto fee increase in the CLI/GUI should not have been triggered according to what I understand. 17:11:12 I do support further research on rings, even if I'm hopeful to replace them quite soon 17:11:36 kayabanerve: In seriousness, CLSAG with higher ring size is proven battle-tested technology/cryptography. FCMP is not (yet). 17:12:02 3) Discussion on Research Pre-Seraphis Full-Chain Membership Proofs. @kayabaNerve @UkoeHB @AaronFeickert @cypherstack https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86 17:12:36 It's also known to be vulnerable, but I wouldn't expect it to be forgeable. 17:12:38 see jtgrassie's comment at the bottom; is this description still valid? https://monero.stackexchange.com/a/11658/42 17:15:01 The scaling proposal will include lowering the surge of the short term median from 50 to 16. Combine this with ring 64 CLSAG and the math for a black marble attack gets real tough 17:15:16 sgp_: selsta can answer about what exactly `wallet2` does (or is supposed to do) with automatic fee increases. 17:15:41 I'm available for questions. This meeting, I'd call for agreement FCMPs replacing CLSAG is a valid goal and if it works out, should be integrated and deployed. 17:16:28 AFAIK the multipliers there are out of date. 17:16:36 Those fee level are for before the last HF in 2022 17:16:45 I'm disinterested in drawing this out for months and having it as delayed as Seraphis. I won't ask to rush it, yet I personally see an efficient path forward and would like to take it. 17:17:06 @kayabanerve I am full of hope for FCMPs but I wouldn't rush them too much until they are properly peer reviewed and audited, also their implementation. 17:17:14 If someone knowledgeable could update that SE post with the latest info, that would be appreciated :) 17:17:48 The linked proposal is comprehensive to the steps of review and auditing. 17:18:01 if there is a backlock or the last block is 90% full -> priority 2, otherwise it selects priority 1 17:18:06 FWIW, I fully support focusing on FCMP that can replace CLSAG before Seraphis. 17:18:10 anowitz: kayaba's proposal is quite thorough with the review process needed; is there any part of this that you feel in inadequate? 17:18:19 Question from a crypto-noob: What is described there in the FCMP gist probably works out, i.e. probably doesn't contain something that totally does not fly? 17:18:43 I have multiple months budgeted for its review in my timeline. One of the first steps on the list is immediately having Aaron Feickert: provide proofs of security for GBPs. 17:18:49 but i don't know what mobile wallets are doing, it's possible they have different auto fee selection code 17:19:07 It has multiple fallbacks rbrunner 17:19:34 If the super efficient DLog proof fail, we have less efficient ones. 17:19:38 There is a need for clarity on fees. I will address 17:19:54 So if there is a problem it probably a quite subtle one, that only a detailed analysis will show 17:20:00 They're still tolerable IMO. As slow as 3 16-out Bulletproofs. 17:20:32 I will repeat what I said on Monday about time allocation for mathematical security proofs: 17:20:34 IIRC "Fail fast and early" is a project management principle. Maybe a single large CCS by Cypher Stack could have this decision tree: 1) Try to write a security proof for GBP. If succeed: 2a) Research "FCMP on RingCT". If fail: 2b) Do the proposed "Seraphis General Paper Review". (2a) would also require another entity to review the security proofs before mainnet. (2b) could mean t hat another entity tries to write GBP security proofs. 17:20:50 No. Several components may not live up to expectations re: intended performance. If one doesn't, it's still acceptable IMO. 17:21:04 Does the "less efficient ones" still require GBP? 17:21:08 To be clear, a security review for GBP would apply to both FCMP-for-RingCT and FMCP-for-Seraphis 17:21:12 That leaves with almost everything having to fail for the effort to fail. 17:21:19 They both use the technique 17:21:31 So I believe it's quite tolerant to setbacks. 17:21:35 kayabanerve: what are the new crypto libraries that you would need to introduce to have FCMP working now? 17:22:22 I am also calling for proofs of all the components, have extensively timelined review, and it'd start with proofs of GBPs which at the biggest concern re: if they fail to work out. 17:22:33 BTW, due to kayabanerve's proposal, I revisited my tower-cycle for Ed25519 and managed to find an even better one where both curves have a = -3, which allows for more efficient formulas to be used. 17:22:46 I +1 FCMPs replacing CLSAG is a valid goal pre-Seraphis 17:23:01 Where do those "GBPs" come from? Somebody else invented them? 17:23:08 Rucknium: We could deploy a non-GBP variant if the divisor technique maintains its performance. 17:23:50 @dangerousfreedom Two curve libs, GBPs, divisors, the circuit, and some util libs 17:24:09 We can near immediately start review + audits of GBPs + divisors 17:24:16 kayabanerve: So we could flow: Try GBP security proofs. If unable: Try security proofs for Eagan's divisor technique. If unable: Start math review of Seraphis. 17:24:30 I mean for CypherStack's work 17:24:46 Happy to hear tevador. I'd love to have you contribute the impls, though they do probably have to be in Rust to minimize FFI traversals :/ 17:25:04 (Not an issue on the scale of the proof, an issue on the scale of EC adds) 17:25:09 Sorry forgot about this again, present in meeting now 17:25:22 kayabanerve: Your proposal would require monerod to include Rust code. Is this correct? 17:25:32 rbrunner: Authors of curve trees, with Aaron Feickert: having notated it 17:25:54 What does "notated" mean? 17:26:01 I'd have to check with Aaron Feickert: if they want to work on the divisors. 17:26:41 Eagen claims the techniques are common with BP++'s permutation argument, so Aaron may have prior experience and the appetite. I'd check before assuming. 17:27:18 Is already clear what Monero with FCMPs would probably mean for hardware wallets? 17:27:19 I have a meeting in two hours to discuss divisors and circuit auditing with a firm for what it's worth. 17:27:36 kayabanerve: You are aware that Aaron Feickert was unable to verify Eagan's BP++ security proofs, right? If they are the same as for the divisor technique, then? 17:27:38 Yes to needing Rust, unless completely rewritten. 17:27:50 (That's also a concern for Seraphis and Jamtis, of course) 17:28:43 Notated means Aaron literally typed up the modifications to the protocol that were proposed by the curve trees authors. 17:28:47 @Rucknium: we documented the GBP protocol, but did not prove it secure 17:29:00 It was not documented previously 17:29:04 The curve tree authors only commented the theory of the math, and did an implementation. 17:29:29 But yes, it is correct that we did not find all BP++ security proofs convincing as written 17:29:34 rbrunner: Hardware wallets would have reduced memory use, actually. 17:29:45 I understand. GBP was "left as an exercise to the reader" in the Curve Trees paper basically. 17:29:58 Rucknium: correct 17:30:11 I think the "bottleneck" for hardware wallets would be: How much new code, and what kind of code, would they have to implement? 17:30:13 They'd do a addendum proof, not the FCMP. This achieves the same proof separation as Seraphis. 17:30:29 Rucknium: The two sets of proofs are completely distinct. 17:31:20 "They'd" refers to the hardware wallets. 17:31:52 It'd be a generalized schnorr protocol of 4 points and three scalars. 17:32:19 It's a very simple protocol comparable to doing multiple schnorr signatures. 17:32:48 It'd also have the same additive blinding currently used w.r.t to the private spend key. 17:33:37 Sounds like "doable" as you describe it, then 17:33:46 Clarifying here, BP++ claims to use similar algebraic techniques to divisors. I'm aware Aaron wasn't convinced for the BP++ proofs. This is a much smaller topic with much more provenance. 17:34:21 Aaron may be interested in reviewing divisors, or they may not be. I'd have to ask. 17:34:49 Aaron Feickert: Would you be interested/claim to be capable of reviewing elliptic curve divisors as posited for use here? 17:35:14 AFAIK the main goal of today's meeting is to get as far as we can on developing a CCS proposal for Cypher Stack (AFAIK Aaron Feickert /Sarang doing most or all of the work) to work on mathematical security proofs and/or review of proposed cryptography for MRL for the next couple of months. 17:35:17 Would need to know the precise scope of this 17:35:24 Noob question, would supporting pre-Seraphis FCMPs require address generation/changes ? 17:35:39 But yes, I'd like to know what, if any, proposals from Cypher Stack the community would like to see 17:35:51 Right now Diego Salazar has one open for Seraphis 17:36:13 Eaten posted the calculation of an elliptic curve divisor which interpolates a series of points as useful for proving in-circuit an output point is the sum of a series of points. 17:36:14 *Eagen 17:36:25 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/441 CS' open CCS 17:36:28 I'd previously commented on a few possible research areas https://github.com/monero-project/meta/issues/986#issuecomment-2030089046 17:36:48 They commented specifically on challenged evaluation, preventing forgeries, and using the logarithmic derivative to minimize in-circuit multiplications. 17:37:08 It's quite heavy on the group structure of the curve itself. 17:37:25 AFAIK no 17:37:40 No new address/privacy pool. 17:37:59 Well, that would probably also kill it as pre-Seraphis thing, no? 17:38:23 So lucky that we don't get new addresses ... 17:38:24 Aaron Feickert: I wouldn't mind having you also review divisors. I know you believe the review of the circuit may be best done by others. Would you also volunteer yourself as a candidate for this topic? 17:38:41 Something something Weil, Picard group? 17:38:52 kayabanerve: Can you remind me the source documentation for this? 17:39:10 And how you'd intend for this to fit in with any other desired research? 17:39:21 Eagen's EC IP proof using divisors as an IACR preprint. 17:39:50 https://eprint.iacr.org/2022/596 17:39:52 That's it, thanks 17:39:55 Is the current thinking still that much of the work done for pre-Seraphis FCMPs will carry over to Seraphis without massive additional effort? 17:40:09 FWIW, I fully support focusing on FCMP that can replace CLSAG before Seraphis. <= +1 17:40:41 Section 3.2, not 4.*. 17:41:26 On a brief glance, I don't see any particular security model, formal statements, or security proofs 17:41:38 Meaning it's not clear what exactly I'd be doing 17:41:43 I want to use the logarithmic derivative to efficiently prove sign-agnostic (x-coordinate only) knowledge of discrete log. 17:41:44 I also want to use the derivative to prove a series of bits is the discrete log. 17:42:00 They do comment on correctness/soundness, albeit potentially briefly. 17:42:17 3.2.1 17:42:32 3.3.1, 4.2 17:42:38 The authors only vaguely refer to the idea of soundness 17:42:49 TBH I am not interested in trying to extrapolate the intent of the authors 17:42:59 It's legitimately largely commentary on the algebraic nature of curves with a posited usage. 17:42:59 That is not a good use of time 17:43:24 If the authors intend to convince readers of formal properties, they need to state those properties and provide proofs 17:43:36 Sorry to be so blunt :/ 17:44:10 rbrunner: The proof itself would largely carry. The circuit would change. The integration would move to being integrated with Seraphis. 17:44:21 But the proof and techniques and review and audits carry. 17:44:44 Aaron Feickert: To be fair, I wouldn't ask you to certify the paper. I'd ask you to do the second half. 17:45:05 Say more about this? 17:45:29 That paper is on techniques and a posited use case. We'd need to design a R1CS gadget building on those techniques to offer a sound proof. That's what would be proven. 17:45:57 Designing a security model, formalizing the approach, and proving it secure is quite the ask 17:46:06 Much more than "review this preprint" :D 17:46:10 Also, divisors predate Eagen's writings. They apparently have extensive history when you read into them. 17:46:22 Things are getting a bit complicated and if they get even more so it really will take resources from something like Seraphis, no? 17:46:26 Sure, but that's much different than what I see here 17:46:33 Regardless, if they don't work out, we'd fallback to incomplete addition in circuit. It'd be fine. 17:47:15 The idea is to move quickly with this. Seems to me some proof / review work needs some parallelization, i.e. more capacity than simply Aaron's 17:47:22 Aaron Feickert: You have to understand the techniques posited and grok the idea of usage to take that next step ;) 17:47:24 I just want to make clear that "review this preprint" is not the apparent ask here 17:47:29 Incomplete addition in circuit = how much worse performance in verification time and tx size? 17:47:36 You're welcome to bow out and/or sign up for review of the fully posited gadget (again, I'm meeting another group in 2h about this) 17:48:26 I don't want to push Aaron Feickert: out. I'd explicitly next ask them to work on proving GBPs and suggest a distinct group for the divisor work currently posited. 17:48:32 What I figure could remain pre and post-Seraphis with FCMPs on the integration side: the flow of adding/removing to/from the tree in lmdb (even though the elements in the tree will be different), setting up the FFI to the Rust code for prove and verify, the logical flow of verify in the daemon 17:49:09 kayabanerve: I don't fully grok what the ask for divisors is 17:49:20 Rucknium: I believe 2x in time, but I'd have to redo the layout and check. No notable diff in size. 17:49:21 We decline to do the divisor preprint at this time. 17:49:25 "I'd explicitly next ask them to work on proving GBPs and suggest a distinct group for the divisor work currently posited." That sounds good to me. If we can get more people working on the formal security proofs, great. 17:49:36 rbrunner: Yes, my entire proposal is around multiple parallelized tracks. 17:49:48 The biggest change for post-Seraphis integration is probably switching curves and all code surrounding that. My initial estimate seems something like 30-50% of the work would be done 17:50:09 On the coding side, right? 17:50:10 jberman: And a lot of the cryptography ;) 17:50:36 of course, was talking strictly about integration :) 17:50:38 Aaron Feickert: , though this was a bit brief. 17:50:59 Doesn't sound too bad. 17:51:11 @jberman If this goes well, it may justify not moving curves. It also may further justify moving. 17:51:24 Together with the estimate that most of the "theory" side will carry over almost effortlessly 17:51:31 rbrunner: Parallelization of coding, review, and auditing. 17:52:01 Hope you don't rush headlong into a burnout with this ... 17:52:40 If all goes well probably have the time of your life :) 17:52:48 We could near immediately start formal review of parts, formal proofs of parts, and audits of parts of the code, while the next steps off those start development so they're ready for review when the prior wave finishes review. 17:53:12 Stepping back, given this discussion, what would be the desired proposals (if any) from Cypher Stack going forward? 17:53:23 GBP proofs. 17:53:24 There's no sense having a Seraphis review proposal open if this isn't the desired timeline 17:53:49 Even with the understanding that this could yield effectively no deliverable? 17:53:57 That's my immediate comment/request/priority/urge from this community. 17:54:23 Suggestion: Create a CCS proposal to put Cypher Stack "on retainer" for `k` months. Have a flexible plan of the menu of things they would be willing and able to do. Start with the plan and then set tasks based on intermediate outcomes of the research. Create a MRL committee to make the decisions about what the task flow should be as results come in. 17:54:23 (as in, it needs the community to agree, and I urge the community to agree) 17:54:34 Literally all of life ;) 17:54:39 The Seraphis proposal can either be rewritten for GBP proofs or temporarily put on hold whilst a new one is put out 17:54:57 So yes 17:54:58 Rucknium: I'm obviously biased on this topic, but how would tasks be defined and chosen? 17:55:07 I know that people claim differently, but I am pretty sure that Seraphis won't progress much until we hardfork to this new thing. So now review now does not seem to be a big loss. 17:55:29 I ask because such a committee doesn't currently exist :D 17:55:34 Other suggestion: A CCS proposal for FCMPs pre-Seraphis which covers its needs, with a well-documented set of intents and allowances. 17:55:34 rucknium: If such a proposal would be posted, it would have to at least include some examples of what Cypherstack is going to work on 17:55:55 I'm sorry to try to streamline things in this meeting, but I'd like to circle back to Cypher Stack's immediate upcoming work. 17:55:56 Choose who will be on the committee. This structure avoids having multiple CCSes and the delay that involves. 17:55:57 From developer(s), to CS (if not independently CCS'd), to other groups. 17:56:11 If the answer is "we don't really have an answer yet, that's fine. That's the answer." 17:56:23

Other suggestion: A CCS proposal for FCMPs pre-Seraphis which covers its needs, with a well-documented set of intents and allowances. <= Think this would actually be the best, as it will be specific and to the point 17:56:38 Aaron Feickert posted a possible list of things to work on: https://github.com/monero-project/meta/issues/986#issuecomment-2030089046 17:56:53 dEBRUYNE: Seraphis isn't inherently changed by this since it's a composition. We'd prove FCMPs meet the requirements of the composition. 17:57:36 I'm not against a CS retainer, starting with GBPs, and a FCMP slush. 17:58:06 That sounds optimal to me if we can agree on it, with further tasks defined however/whenever. 17:58:33 kayabanerve: Do you prefer a retainer over the specified proposal you mentioned before? 17:58:34 (further tasks re: CS) 17:58:34 AFAIK, no one is speaking up for a Seraphis paper review. If no one wants that in the near term, then that's fine. 17:58:52 The FCMPs side is already well defined 17:59:20 Rucknium: I'll explicitly chime in I don't have thoughts there :p 18:00:13 dEBRUYNE: I don't mind if CS has a retainer, is contracted for GBPs in a CCS, or is contracted for GBPs under the FCMPs slush CCS. It's up to y'all. 18:00:37 Diego Salazar: would appreciate the retainer and I'm sure we have enough work for them, so I'd say retain CS. 18:00:40