01:34:45 when is the next meeting? 01:35:34 Check github meta issues 01:35:47 Same time every week 01:35:56 If i knew, id tell you 01:36:36 https://github.com/monero-project/meta/issues/1256 01:36:40 https://github.com/monero-project/meta/issues/1261 01:36:51 https://github.com/monero-project/meta/issues/1261 01:36:53 Yea 12:30:03 Is the meeting ok to attend for all ? 12:30:31 Absolutely 15:02:49 MRL meeting in this room in two hours. 17:00:50 Meeting time! https://github.com/monero-project/meta/issues/1261 17:00:51 1) Greetings 17:01:00 Hi 17:01:11 Hello 17:01:17 Rare hi from me 17:01:24 Hi 17:01:26 *waves* 17:02:54 2) Updates. What is everyone working on? 17:03:11 Ping jeffro256 17:03:45 Howdy 17:03:50 thanks for the ping 17:04:29 me: Reading papers about selfish mining countermeasures and decentralized consensus protocols. Helping test rolling DNS checkpoints on testnet. Making fixes to moneroconsensus.info and moneronet.info 17:05:04 me: working on special build for dns checkpoint testing, and looking at carrot+lws stuff 17:05:15 me: fixed a couple bugs testing forking from current testnet (in the migration and in scanning), cleaned up the FFI (removed unwraps/asserts, used int error returns, de-duplicated some code with macros, clippy+fmt), implemented consolidated paths in the RPC for getting paths in the tree by global output id, reorganized curve trees db logic into a saner structure in prep for PR(s) 17:05:17 to the main monero repo, tested kayaba's latest prove/verify optimizations (good results!!) 17:05:44 me: researching selfish mining countermeasures (Hi) 17:05:51 Repeating from NWLB: good news for the stressnet: kayabanerve implemented linear prove() times, dropping 128-input tx construction down from 5m30s to ~1m!! Huge 17:05:56 me: initiated communication about Carrot follow-up review by Cypherstack, updated FCMP++ benchmark tool for all the latest FCMP++ changes (github.com/jeffro256/clsag_vs_fcmppp_bench/), working on supporting high input counts in benchmark tool, working on patches in Monero core repo, re-reviewing the de-dup PR by rbrunner7, reviewed several PRs in seraphis-migration, did a write-up for an upcoming vuln disclosure, helped prepare v0.18.4.2 release. The de-dup PR does a great job at naturally excluding nodes from the known spy node list, which is great! https://github.com/monero-project/monero/pull/9939/#issuecomment-3228779989 17:05:59 I updated my comments on the FCMP++ weight function. I am also working on a full write-up on Monero s calling generally. 17:06:01 I am also working on the block signing remix 17:06:47 monero-oxide migration, optimizations and improvements. 17:09:34 3) [Carrot follow-up audit](https://gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb). 17:11:00 In communication w/ Cypherstack right now, clearing up scope and such b4 a quote. Is there anything about the scope that people here think should be changed? 17:11:12 Or object generally? 17:11:41 Or any questions? 17:11:56 It LGTM 17:13:31 Same here - as far as I understand such stuff ... 17:14:21 One broad point about the scope we could try to tackle now is adding security arguments for a quantum-resistant migration. 17:15:15 The amount commitments opening should be quantum resistant, the openings for address spend pubkeys I'm less sure about. Going down that path would surely expand the scope significantly. We could also try to tackle that later 17:15:31 Or we might deem it unncessary 17:15:52 I would lean toward NACK on that for now since we have more auditing to get through to take fcmp++ to mainnet 17:15:54 and Carrot 17:16:37 I would generally agree, but the option is there 17:17:12 Are the reasons for the protocol tweaks specified somewhere? 17:18:13 Yes, but it's scattered about in different git commits. I should write down the rationals in one place 17:18:42 Yes, I think it should be part of the scope (to verify that the goal of each change is achieved). 17:19:05 I haven't reviewed this and have no comment other than deferral to jeffro 17:21:53 Any more discussion of this item? 17:22:30 @tevador: 17:22:31 By adding the amount to the derivation of the amount blinding factor, we add ~32 bits of security to Carrot-style openings of the amount commits, which potentially allows quantum-resistant migrations in the future. 17:22:33 By removing the cofactor clear, our X25519 ECDH is A) faster, and B) easier to tweak a standards conformant library to get correct results. 17:22:35 By removing K_s from anchor_sp, for accounts where there are two or more main addresses (i.e. hybrid key hierarchies), you would have to calculate-and-check anchor_sp that many times (which is not secure against collisions), or disable special enotes to yourself. 17:22:37 By removing K^j_v from d_e, once s_sr (the X25519 ECDH exchange in normal enotes) is derived, you no longer need the private view-incoming key or subaddress table to scan normal enotes, which simplifies the scanning code. 17:23:38 OK, I think we can move onto the next item. 17:24:18 Generally agree with tevador's idea that above rationale makes sense to include in scope 17:24:41 4) [Discussion: Replace Monero's hash-to-point function with the FCMP++ Upgrade](https://github.com/monero-project/research-lab/issues/142). 17:26:30 We rely on the hash to point to be a collision resistant hash function to resolve the burning bug. The current HtP isn't a good CRH. We can add a new HtP in ~10 lines. jeffro256: volunteered to update the codebase so all CARROT outputs, already a new type, define their key image generator via a HtP. The FCMP++ upgrade makes it trivial to update the HtP. I've discussed this as a po I wrote my opinion on github. I don't think that the change is worth it. The security benefit is questionable. 17:26:31 tential change for over a year. I just finally did the work to review our existing HtP and confirm it _should_ be replaced. 17:27:14 tevador has prior advocated against the change due to the marginal increase in security. I'll note that while there's an explicit marginal benefit, the hash function also has implicit bias I'm not sure has ever been formally bounded. 17:28:07 Even the unbiased version I'm proposing is bounded to 10/sqrt(q), so ~123 bis of security to my understanding. That raises the question of how much worse the current version is. 17:28:43 As to whether the security is worth it, I leave that to people smarter than me. However, if there is a valid argument for the increase in security, I am willing to update all my relevant code to handle that change. 17:29:50 We can also make more than 10 lines of edits (100 lines?) To become standards compliant, as we *almost* are compliant with what became the standard, and optimize the resulting function by ~20-40% (but this isn't a performance critical fn after FCMP++). The main benefit is anyone who _uses_ Monero _without_ using the Monero C++ would be able to write a key image generator function without writing bespoke elliptic curve arithmetic (due to any impl of the standard being relevant). 17:30:21 If we define the security of our protocol as the security of the weakest component, I wouldn't be surprised if this HtP was _technically_ it. 17:30:30 It will be far more than 10 lines of code. Just the fact that RCT and FCMP transactions will coexist for some time will need to be coded for. 17:30:42 my opinion, ^ I have been bitten by the bespoke ec math for hash to point specifically, otherwise I was able to make everything else using generic libraries 17:30:44 From my view: the benefit seems pretty small, and the change seems pretty small as well. It adds some complexity to manage as tevador notes 17:30:54 The unbiased hash to point function is ~10 lines tevador 17:31:20 The _call sites_ will be more, hence why the old RingCT code remains as-is and we use the separation _already introduced for CARROT outputs_ for the new HtP. 17:31:34 We already have to delineate old outputs from CARROT outputs. cc jeffro256 17:31:43 FWIW in tree building we do already have an indicator determined by whether or not an output is Carrot or not (if Carrot, then consensus already made sure the output does not have torsion) 17:32:09 So it wouldn't be such a major change to introduce in there 17:32:13 Even if it is just a few bits or just half a bit, we shouldn't sacrifice them for naught. The moment we realize any cryptography, we realize losses in our security. Our job should always be to minimize those. 17:32:43 Else, these will add up and add up, and we'll end up with a protocol whose practical bound is lower than desired. 17:32:46 On the flip side, if someone wants to write a Monero wallet that can deal with older txs pre-FCMP++, I figure they would still need the old hash to point implemented too 17:32:47 Since the biased function is based on Elligator, its security might have been already studied. Could be worth looking into it more. 17:33:16 It has, and the recommendation for an unbiased version when you need a CRH is from that research. 17:33:35 Also, the 10 / sqrt(q) bound for calling it twice and summing the result is from an Elligator author. 17:34:02 You wrote above: "the hash function also has implicit bias I'm not sure has ever been formally bounded" 17:34:41 It depends on the exact curve parameters due to the reduction from the order of the field the curve is defined over to the order of the curve. 17:35:15 You'd need research specific to Curve25519, which may scrape by due to how small the primes are after the leading bit? 17:35:19 FWIW, working with Carrot outputs in the Carrot libs already don't use much of the higher-level key image helper functions that the current code uses, because those are meant for univariate key images and the API would have to be modified 17:36:13 But that research has been largely forsaken AFAICT because there's other reasons for bias leading people to simply invoke it twice for am unbiased variant, and formalize the bias on that instead 17:36:42 It's pretty likely that the bias is exactly 1 bit since it covers half of the curve. 17:36:53 But you're right, I may have missed a prior formalized bound for single-invocation Elligator over Curve25519 17:37:39 tevador: I'm pretty sure some resulting points appear more frequently due to the difference in orders. 17:38:58 It's possible. 17:39:15 It's part of the commentary from Hamburg when the IRTF standardized hash to points. 17:39:47 That's the 'implicit, unformalized' bias I'm gesturing at. 17:40:09 But again, Curve25519 moduli are favorable _and_ the torsion clear may also be beneficial? 17:40:34 It's just a such a mess we can either research it or fix it, and it's the perfect time to fix it. 17:40:37 I think we should investigate and also model worst case attacks. I think even if you can find a collision in Hp, I don't think it implies you can burn an ouput. 17:40:50 See jberman, jeffro256 noting we have the perfect spots to deal with this. 17:41:11 It does because if you have the outgoing view key. 17:41:35 You can create two outputs with the same discrete logarithm for their key image, and then you solely need a key image generator collision to perform a burn. 17:42:34 For RCT it does not imply burning an output. I'm not very familiar with Carrot. 17:43:02 It's an FCMP++ comment, not a CARROT comment. You're right for RingCT. 17:43:36 If FCMP is more vulnerable than RCT, the update can make more sense. 17:43:36 FCMP++ allows users to publish what _were_ RingCT private spend keys and are _now_ FCMP++ outgoing view keys for _newly created wallets_. 17:44:05 The only reason that's safe is because the key image generator is a CRH binding to the outgoing view key _and_ the private spend key. 17:44:43 See the difficulties Seraphis had with the burning bug, leading Seraphis to define the outgoing view key as a point _and_ a scalar whose ratio formed the linking tag. 17:44:50 ^ I don't think this was mentioned in your proposal on github. That's a pretty strong point. 17:45:17 I did say we require it to be a CRH to stop the burning bug 😅 17:45:32 But I'm sorry I didn't provide sufficient context/background on that 17:45:35 Although it might be that if people scan CARROT enotes honestly, they can always avoid a burn even if the hash-to-point is not coliision resistant since it would always be the case that x!=x' for some O = x G + y T and O' = x' G + y' T if O!=O'. 17:47:03 I don't believe so since they only have to be able to scan one of them, not both. 17:48:53 Yes, and the other one is guaranteed to have the same one-time address EC point. Assuming the receiver is scanning honestly (and thus recomputes the one-time address as a function of their spend pubkey), only the receiver should know the discrete logarithm of that point, so the other can't spend it 17:49:27 IMO, this has sufficient feasibility and acknowledgement to move forward, at least within the scope of this meeting which is 50m in over only a few topics. 17:49:29 jeffro256: No, they aren't. 17:49:40 They're guaranteed to have the same key image discrete logarithm and the same key image generator. 17:49:58 The whole ides is two different one-time addresses can share a key image if the CRH property of the HtP is broken. 17:50:42 They're allowed to have distinct `y` values. 17:51:30 Discussion can continue in the GitHub issue and next meeting. Thanks. 17:51:37 5) MRL rooms moderation. 17:51:47 SyntheticBird: You suggested this item. 17:51:56 Hi 17:51:59 Yes 17:52:01 Now, is CARROT sufficient to convert the problem from finding a collision to second preimage, which would remain secure? Maybe. Even if, we shouldn't place that bound on CARROT. 17:52:25 Too much spam & trolling in lounge, not enough kicks or mutes 17:52:54 A member here has sent nothing of value, insulted me for days, and arguably even made a threat. 17:53:38 I have a few complaints regarding the current moderation of the research channel. It comes to no surprise i think that the quality of discussions have degraded in the recent qubic events. What would before be reserved to #monero is now disrupting monero lounge, rarely monero lab. I would like to discuss if there is a possibility to increase moderators in these zones. The discussio ns are not constructive, arguments repetetive and often turns into shilling fight whenever a random or a bot comes in to stir the pot. 17:53:53 more moderation would be welcome 17:53:59 If the increase in moderator is not justified then I would ask the moderators to be more strict 17:54:02 Conversations should move according to the procedure: #MRL (heaven) -> #MRL-Lounge (purgatory) -> #Monero-Beef (hell). 17:54:04 I think that CARROT converts the problem of finding the same x to also finding a collision on the hash-to-scalar, but I'll think about it some more. Though I do agree that it's a bit sketchy for CARROT to have that bound 17:55:06 I dont even think beef is necessary for a lot of this, not that lounge is purgatory. some of these topics arent "off topic" but are time sinks and distractions 17:55:13 Yeah ngl, interestingband case is kind of annoying. He have a beef with the people with permissioned which either ignore him or maybe do not want to appear like mod abusing. But he has passed the point of being constructive 17:55:13 I'm not sure how moderation can work with the relays, at least from the IRC side. But I agree that this room should be more strictly moderated. 17:55:30 "Stir the pot" and "producing more heat than light" should be avoided in all MRL rooms, observed voluntarily on the part of participants, if possible. 17:55:51 some pretty lazy attempts at manipulation/subversion happening in lounge on regular basis since qubic 17:56:24 Rucknium: I totally agree and in the fact no moderator intervene when this is obviously the case. 17:56:38 even to the point of harassing devs just to waste time 17:56:40 I have been trying to sync up the new bridge to deploy it soon, probably starting with specific monero rooms first. It can make moderation from Matrix side easier, as each user on IRC will appear distinct 17:56:42 A scientific tone is appreciated. 17:56:44 And worse, long term members (..and mods) are dragged into it and make it worse 17:57:12 It's not just a matter of ban but also telling people to stop the false discussion because its disrupting other to introduce another useful talk 17:57:22 Mapping of bans/kicks on each side is a feature that it has, although not widely tested (and relay on irc side would need at least half-op rights) 17:57:29 I think lounge should be related to work, and people working 17:57:35 Not AMA 17:57:47 This is in response of your ask about relays, tevador 17:57:55 DataHoarder: thanks 17:58:26 I think that any kind of hyperbole in that channel seems detrimental 17:58:28 monero.social Matrix gods allow, this should finish syncing up today (it's up to the 25th of July now, it has been syncing up from 2024 events) 17:59:09 DataHoarder has been MVP recently 🎉 17:59:16 DataHoarder, very excited to see the new bridge operational 17:59:20 (Not minimum viable product, but most valuable player) 17:59:37 I was MVP 20+ years ago :) 17:59:50 Can i be the lowercase mvp? 17:59:52 People find their way in these channels and usually get asked to move elsewhere for specific discussions, but some just ... continue 17:59:54 I think first things we could try get a rough consensus on is whether new moderators are necessary 18:00:10 after that, a mute or enforcement could be necessary to prevent channel spam 18:00:13 Any more to say on this item? 18:00:23 [@diego:cypherstack.com](https://matrix.to/#/@diego:cypherstack.com) cc 18:01:11 Rucknium: i think i'm good, the discussion can happen later. 18:01:46 isn't Rucknium mod here and in lounge yet? 18:01:48 keeping out Qubic sock puppets and concern trolls IMHO is paramount, otherwise valuable discussions and valuable contributors will be turned away from participation. the current admins seem to be MIA. I wouldn't mind having more of them. 18:02:05 No 18:02:18 I'm not mod of any room. I was mod of -beef 😢 18:02:34 Butcherium 18:02:45 You are 😆 18:03:12 I prefer not to have mod powers because mod powers involves you in controvery unnecessarily, but if it's for the collective good, then I can get mod powers. 18:03:27 The collective good has spoken, it seems. 18:03:41 you moderate meetings here, lounge can be handled by banhammer 18:03:52 lounge can be handled by ruck 18:03:57 [Note to IRC side: I am admin now in Matrix MRL room] 18:04:03 I'd volunteer, but yknow how that goes 18:04:07 if he wishes so tho 18:04:27 6) [Transaction volume scaling parameters after FCMP hard fork](https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). 18:05:00 Lel 18:05:04 articmine updated comment today 18:05:20 Rucknium: I prefer turkey 18:05:39 I'm still not understanding why the disincentive should be so strong for 128-in versus 16x 8-in 18:06:16 chain bloat 18:06:21 My thought on this is that we can separate the weight that is due to proofs from the rest of the transaction weight and then apply a function so that after the quadratic penalty the fee tracks verification time more closely 18:06:33 chain bloat is easier with lower input txs 18:06:50 https://github.com/seraphis-migration/monero/issues/44#issuecomment-3228882784 18:06:56 mea culpa i thought the opposite 18:07:32 1 and 2 input txs are the longest verification and highest size 18:07:34 if one want to maximize spam with mined transaction the smallest weight is optimal 18:07:57 sinnce this is where the penalty is lowest 18:08:48 So there is a case to counterbalance this by favoring large transactions 18:09:38 I'm not sure I fully follow, Artic are you proposing to update the original proposal with new forumlas? 18:10:27 2c: If fees are set linearly per-input, higher input txs end up paying more per byte than lower input 18:10:32 If we want the fees to be close to linear with verification time then we will have to apply a weight formula to favor large transactions 18:11:13 So if this is the wish of the community then yes 18:12:03 My main concern here is that the transactions be economic to mine 18:12:11 linear would mean that it is roughly comparable cost to construct 16x 8-in's compared to 1x 128-in, not to make one more favorable than the other 18:12:32 Yes 18:12:38 I think we should set an 8-in/4-out limit and not _have_ large transactions. 18:12:41 (although I think there is a stronger argument for 16x 8-in's to cost more) 18:13:14 This needs a square root weight formula on the proof part of the weight 18:13:22 Alternatively, a linear weight sounds fine without favoring either side. If anything, I'd call for large TXs to pay notably more than smaller TXs to provide an economic incentive for people to move to small TXs, as we may require in the future. 18:13:51 My point is we can tune the weight formula to what ever is desired 18:14:00 P2Pool coinbase outputs :) 18:14:07 Why should my wallet bloat the chain by splitting my tx into 16 instead of just sending the damn thing 18:14:26 ofrnxmr: Transaction uniformity. 18:14:32 those tend to be plenty, and small, which with this change would make using p2pool more expensive than a centralized pool due to even higher fees 18:14:45 And again, this may become a hard requirement in the future. We want people to get prepared now with solutions now. 18:15:06 I have been told no to 8/4 and I think you all are horrible people who hate privacy and don't understood anything /s 18:15:20 me but unironically 18:15:22 Tx uniformity would be a fixed 1 or 2 input tx, not 8 4 2 1 18:15:36 So i propose we separate the proof parts of the total weight from the rest of the transaction weight, then I can provide options for consideration 18:15:42 On a legitimate note, if we have an end goal of uniformity, we will decrease from 128 in. I understand we aren't doing so now. We should still nudge people towards less and less inputs per TX. 18:15:51 8 in/4 out is a valid uniformity target ofrnxmr 18:15:58 Dummy inputs/dummy outputs 18:16:28 > I intend to break out membership proof size and verify time into 2 additional columns 18:16:32 I can do this today 18:16:56 my input count on ringct has privacy issues (cospends). What issues for fcmp? 18:17:05 4/3 is a minimum established by CARROT. 18:17:58 ..afaict, uniformity doesnt add privacy w/o knowledge linking the inputs together 18:18:39 And with fcmp, its my understanding that the history of the inputs arent linkable to their origins 18:18:53 I (non-sarcastically) agree reducing the number of in/out combinations is a legitimate and viable way toward tx uniformity, and would nudge people toward that even without universal dummies and IVC 18:19:22 ofrnxmr: More inputs signifies you're an exchange or service provider. 18:19:30 no it doesnt 18:19:46 It's a long-term goal for all TXs to be indistinguishable, which would include fixed input/output count. 18:19:47