<f​r33_yourself:monero.social> My opinion regarding the idea of limiting maximum inputs to 8 is that it could be bad for merchants when they want to consolidate. I read what kayaba wrote up on github and the conversation here. I'm not so sure that having a function in the wallet that automatically consolidates will be good enough. Because even if you have this it will still be troublesome and slow (20 min wait <clipped me

<f​r33_yourself:monero.social> time for each consolidation) to consolidate and sweep their received coins. Monero has the best privacy at the moment IMO, and sure FCMP++ give even greater privacy but if the coin is very troublesome to accept as medium of exchange (impossible to spend or consolidate many received inputs into an output) then the privacy gains are all for not. If merchants decide it's too much of <clipped me

<f​r33_yourself:monero.social> a pain to deal with then that is no bueno.

<f​r33_yourself:monero.social> My opinion regarding the idea of limiting maximum inputs to 8 is that it could be bad for merchants when they want to consolidate. I read what kayaba wrote up on github and the conversation here. I'm not so sure that having a function in the wallet that automatically consolidates will be good enough. Because even if you have this it will still be troublesome and slow (20 min wait <clipped me

<f​r33_yourself:monero.social> time for each consolidation) to consolidate and sweep their received coins. Monero has the best privacy at the moment IMO, and sure FCMP++ give even greater privacy but if the coin is very troublesome to accept as medium of exchange (impossible to spend or consolidate many received inputs into an output) then the privacy gains are all for naught. If merchants decide it's too much <clipped me

<f​r33_yourself:monero.social> of a pain to deal with then that is no bueno.

<k​ayabanerve:matrix.org> fr33_yourself: It's 20 minutes for each layer of consolidations, not 20 minutes for each consolidation.

<k​ayabanerve:matrix.org> I'll also repeat how only 3% of TXs would be affected per Rucknium's recent analysis of the last five years, and how merchants already have to consider this as the current MAX_INPUTS is high, but not high enough it's unreachable.

<f​r33_yourself:monero.social> How many inputs per 20 minutes or consolidation layer? I thought you said only 8 per 20 min. What is upperbound on inputs per 20 min that can be consolidated

<k​ayabanerve:matrix.org> There's a logarithmic amount of layers.

<k​ayabanerve:matrix.org> If you have 1 million outputs, you can consolidate them in (log_MAX\_INPUTS(1 million) - 1) * 20 minutes.

<f​r33_yourself:monero.social> I saw your comment. I'm just thinking about how merchants that receive a few hundred tx per day can consolidate when they want to move funds? How would consolidation and sweeping in a reasonable timeframe work post FCMP++ hardfork?

<k​ayabanerve:matrix.org> So for MAX_INPUTS = 8, 2 hours.

<k​ayabanerve:matrix.org> (for an absurd amount of inputs)

<k​ayabanerve:matrix.org> 1m -> 125k -> 16k -> 2k -> 250 -> 32 -> 4

<f​r33_yourself:monero.social> Ok, I'm not sure I fully understand the logarithmic nature of the math, but I'll take your word for it

<k​ayabanerve:matrix.org> It's that final line I just sent.

<k​ayabanerve:matrix.org> 1m outputs is consolidated into 125k outputs, each consolidation transaction only having 8 inputs.

<k​ayabanerve:matrix.org> Then the 125k outputs is consolidated into just ~16k outputs, each consolidation transaction only having 8 inputs.

<f​r33_yourself:monero.social> Let's say someone has received 7,000 separate transactions (inputs) into one wallet in a week. At the end of the week they want to sweep those coins into another wallet. What would this process look like after FCMP++ ?

<k​ayabanerve:matrix.org> So if you have 50 outputs, it's literally just 20 minutes. You make 7 transactions (7 * 8 = 56, which is more than 50) and then end up with 7 outputs 20 minutes later.

<k​ayabanerve:matrix.org> They make ~900 transactions aggregating 7000 outputs into 900 outputs. Then they make ~115 transactions aggregating 900 outputs into 115. Then 15 aggregating 115 into 15. Then they finally sweep two outputs in two TXs to the other wallets. It'd take one hour.

<k​ayabanerve:matrix.org> Under the current MAX_INPUTS, which I cited as 220 in practice yet ofrnxmr says is 120 (which I believe is correct), it'd not be 7000 -> 900 -> 115 -> 15 -> 2 but 7000 -> 70 -> 1. It'd be only 20 minutes but this would still need to be programmed and considered.

<f​r33_yourself:monero.social> And I guess they would write some sort of software to do that? Kinda seems pretty difficult manually performing all of those transactions though

<k​ayabanerve:matrix.org> Yes, as they _already_ do.

<f​r33_yourself:monero.social> How do they do that just curious

<f​r33_yourself:monero.social> Sorry I am a bit of a n00b\

<k​ayabanerve:matrix.org> Eh. You can flood your destination wallet with 70 outputs (per the prior example). It'll just need to do its own consolidation after the second week.

<k​ayabanerve:matrix.org> I'm saying they already have to.

<k​ayabanerve:matrix.org> I can't comment on if/how literal services do.

<k​ayabanerve:matrix.org> I'm noting that today, in Monero, you cannot spend 7k outputs in one TX and already need to consolidate as I describe here.

<f​r33_yourself:monero.social> How do you know that they already have to navigate this challenge?

<k​ayabanerve:matrix.org> Because there's already a MAX_INPUTS in practice?

<k​ayabanerve:matrix.org> I'm not introducing this. I'm just proposing adding an explicit, lower value than the current implicit one.

<f​r33_yourself:monero.social> What's the practical max input again?

<k​ayabanerve:matrix.org> 120 AFAIK

<k​ayabanerve:matrix.org> So for your example of 7000 outputs a week, yes, those have to be consolidated if you want to spend your entire wallet balance at once.

<f​r33_yourself:monero.social> Do you have any guesses how merchants currently handle it? I mean 120 input max per tx is still a lot more than 8 though

<f​r33_yourself:monero.social> so if they are manually performing the transactions by hand in the command line or gui wallet then it probably wouldn't be too atrocious currently

<k​ayabanerve:matrix.org> No idea. I am not privy to the inner workings of centralized exchanges re: a privacy coin which makes trying to reverse-engineer this on-chain near impossible.

<k​ayabanerve:matrix.org> Centralized exchanges are the primary affected group IMO. They're the group I'd see with the most volume who also regularly needs to make transfers out.

<k​ayabanerve:matrix.org> Monero already has some code to handle the case where your outputs don't fit within MAX_INPUTS. `transfer_split`.

<k​ayabanerve:matrix.org> I also noted how transaction chaining allows a wallet running in the background, without the private keys, to handle consolidation (if a user comes online once to initialize it).

<f​r33_yourself:monero.social> Yes I saw that. And it all sounds nice in theory. I just wonder if it will really get implemented that quickly after a FCMP++ hardfork

<k​ayabanerve:matrix.org> So from a UX perspective, this should still be resolvable. More users will have to leave their wallet open in the background, and there will be higher latency for anyone wanting to spend a large value of their wallet funded from a bunch of small inputs, but that's about it. I'll also point out how UTXO consolidation is a frequent topic within the Bitcoin community. This is somethi<clipped message

<k​ayabanerve:matrix.org> ng exchanges and users already face over there, and Monero already faces (even if we don't discuss it as much).

<k​ayabanerve:matrix.org> Agreed wallets needs to take the step after. Wallets needing to do that isn't enough of a problem to justify the fundamental DoS issues with keeping MAX_INPUTS at 120.

<k​ayabanerve:matrix.org> If we did one FCMP per proof, minimizing the computational base cost and allowing as much batch verification as possible, we'd only support 16 inputs under the current implicit limit FWIW.

<f​r33_yourself:monero.social> Thanks for taking the time to address some of my concerns. If it's really not that big of a deal for merchants or exchanges that are receiving tons of transactions, then my concerns are unwarranted. I just worry about kicking those types of people off the network by making it super hard to use. As Monero's use-value is dependent on online merchants or vendors being able to accept <clipped me

<f​r33_yourself:monero.social> lots of fairly small "chunks" inputs, and being able to move them in a reasonable timeframe and with minimal headache.

<k​ayabanerve:matrix.org> I have mixed feelings. I completely agree with you in that Monero has to be usable.

<k​ayabanerve:matrix.org> I also just believe there's risks to the protocol itself without this and we can't risk protocol stability for usability.

<k​ayabanerve:matrix.org> I do agree this will be another annoyance. I fear the risks otherwise would be far more annoying. If TXs did take 2 seconds to validate, free RPCs would disappear or require you spend tens of seconds on PoW to justify even listening to your RPC request.

<f​r33_yourself:monero.social> What's the DOS problem with max inputs at 120? I didn't catch this?

<k​ayabanerve:matrix.org> Right now? None, it's just a large TX. Under FCMPs++? 120 * 15ms = 1.8s verification time

<k​ayabanerve:matrix.org> (assuming a linear growth in proof time from 1 input to 120 inputs)

<f​r33_yourself:monero.social> What are the implications of 2 second verification time per tx?

<k​ayabanerve:matrix.org> I also do believe the usability concerns here *should be mitigatable at the wallet level* and that's where *they should be mitigated*.

<f​r33_yourself:monero.social> That it requires more bandwidth to keep up to date with current blockheight?

<k​ayabanerve:matrix.org> No, we'd presumably lose free RPCs

<f​r33_yourself:monero.social> or is the problem with the initial blockchain sync verification

<k​ayabanerve:matrix.org> If I can trigger your server to spend two seconds verifying a transaction it takes me 20ms to upload, I can DoS you for ages.

<k​ayabanerve:matrix.org> It's a massive asymmetry which allows trivially occupying any free Monero nodes.

<f​r33_yourself:monero.social> Ahhhh I see. So that is what you mean by DOS.

<k​ayabanerve:matrix.org> I believe it would lead to paid RPC access in some form, either explicitly monetary, via PoW (the whole credit system we currently have with calls to deprecate), or via anti-spam PoW (which will be tens of seconds on mobile devices to publish any transaction).

<f​r33_yourself:monero.social> So the game theory would be that people would remove their publicly available nodes or nodes like cake wallet's would get DOS'd

<k​ayabanerve:matrix.org> That's not even to discuss the risk to the P2P layer itself where any node can send you a TX which takes multiple seconds to validate.

<f​r33_yourself:monero.social> Yeah the P2P layer seems like a bigger deal

<f​r33_yourself:monero.social> I mean power users should be running their own nodes anyways.

<k​ayabanerve:matrix.org> It's just an outrageously easy burden to trigger on any publicly accessible node and will likely lead to nodes not being publicly accessible.

<k​ayabanerve:matrix.org> Yeah, such a large computation time has a burden in a lot of places...

<f​r33_yourself:monero.social> It's great for there to be free RPC, but if that went away I don't know how much it would effect Monero's core user base

<k​ayabanerve:matrix.org> Also, I may be somewhat biased as I wrote the code to handle this years ago and don't need to make any adjustments.

<k​ayabanerve:matrix.org> But also, I wrote this code years ago because it was necessary years ago. My proposal to reduce MAX_INPUTS doesn't change its necessity.

<k​ayabanerve:matrix.org> That's a recent proposal

<f​r33_yourself:monero.social> What are the implications of 2 second verification time for the peer to peer layer? Also for bandwidth and staying up to date? And for initial blockchain sync?

<k​ayabanerve:matrix.org> But that also means I've accepted this, been ready for this, and have had years to cope with this. Y'all are only just facing it :p

<k​ayabanerve:matrix.org> If the network got DoSd, any node publishing/relaying a TX would need to include an associated PoW to justify it most likely? I'm not a P2P net person so I can't comment how this would ideally be solved.

<k​ayabanerve:matrix.org> We're likely back to whoever makes the TX spending tens of seconds on an anti-spam PoW *after signing it and proving for it* to justify it.

<k​ayabanerve:matrix.org> But it's such an outrageous burden it isn't 'how do we cope with it', it's 'let's ban that by reducing MAX_INPUTS'

<k​ayabanerve:matrix.org> Setting MAX_INPUTS to 8 actually shouldn't hurt the computational burden of the network. Outlier TXs pay a base cost. Non-outlier TXs share a base cost.

<f​r33_yourself:monero.social> I mean I'm not a high volume merchant, so it's not the end of the world for me personally. My main concerns about FCMP++ are related to bloat in tx size, sync time, and the issue we are discussing about limiting max inputs. I guess making sure the code is sound and no inflation during the hard fork are also important points of focus. I'm kinda neutral on the FCMP++ upgrade. I unde<clipped me

<f​r33_yourself:monero.social> rstand the benefits, but the costs are harder to get my head around. \

<k​ayabanerve:matrix.org> Forcing more TXs to not be outliers, by limiting how far they can be outliers (MAX_INPUTS=8, not MAX_INPUTS=120) means more TXs share a computational cost.

<k​ayabanerve:matrix.org> Also, the cost to verify the Bulletproof for 8 inputs vs 120 inputs is largely linear? It's technically `O(n / log n)` due to the multiexp but I've been handwaving that out.

<f​r33_yourself:monero.social> This seems like a nightmare to implement, so I can see why it would be desirable to keep verification time per tx low

<k​ayabanerve:matrix.org> So verifying 15 8-input TXs vs 1 120-input TXs *independently, not in a batch* should be largely the same.

<k​ayabanerve:matrix.org> The one consideration is that the 15 8-input TXs produces 15 outputs and the 1 120-input TX produces 1 output. That means we do pay a logarithmic cost for the inevitable consolidation of those 15 outputs.

<k​ayabanerve:matrix.org> So it goes from a giant O(n / log n) cost -> an incremented O(n * log n) cost

<f​r33_yourself:monero.social> I'm following

<k​ayabanerve:matrix.org> It's generally always better to handle things incrementally than at-once, even if the at-once cost is cheaper overall.

<f​r33_yourself:monero.social> So what is difference in projected verification time with max inputs = 8 versus max inputs = 120 post FCMP++ hardfork

<k​ayabanerve:matrix.org> (and we do still have a `/ log n` when verifying a one-input proof, it's just less notable as it matters more when n is large)

<k​ayabanerve:matrix.org> was my handwaved estimate though I've not prior benched 120 inputs (solely the one input case)

<k​ayabanerve:matrix.org> 15ms an input

<k​ayabanerve:matrix.org> So with a limit of 8 inputs, each TX can only cause ~120ms of burden.

<k​ayabanerve:matrix.org> The code is sufficient someone can run the benchmark for the 120-input case though, I just find that not productive and haven't bothered

<k​ayabanerve:matrix.org> ofrnxmr: github.com/monero-project/monero/bl…rc/wallet/wallet2.cpp#L11076-L11085

<k​ayabanerve:matrix.org> The full reward zone is 300000. That, div 2, minus 600 (coinbase blob reserved size) is the 149400 value I quoted.

<f​r33_yourself:monero.social> Ok so what again are the exact issues that having the much lower verification time (15 x 8 = 120ms) solve?

<k​ayabanerve:matrix.org> Are you sure there's a further 66% applied ofrnxmr ?

<f​r33_yourself:monero.social> What is the verification time currently for an 8 input transaction? Just out of curiosities sake

<k​ayabanerve:matrix.org> fr33_yourself: It prevents being able to get an arbitrary node to spend 2s, a massive amount of CPU time, off a P2P/RPC request as I said.

<f​r33_yourself:monero.social> versus post FCMP++

<k​ayabanerve:matrix.org> No idea. I referred to the rationale for MAX_OUTPUTS in which this discussion follows, not the current premise with MAX_INPUTS.

<k​ayabanerve:matrix.org> I'm returning to my work so please refer to my post or do your own benchmarking for more information.

<f​r33_yourself:monero.social> max_outputs isn't so worrisome for me personally, I defer to the judgment of you and the others. I was curious about max_inputs only as that has an impact on large merchants

<k​ayabanerve:matrix.org> ofrnxmr: github.com/monero-project/monero/bl…53c454/src/wallet/wallet2.cpp#L9597

<k​ayabanerve:matrix.org> I really think wallet2 is the 149,400 value, per my re-review of the code I prior reviewed when working on monero-wallet, despite my historical belief it was 100kB and your active belief it was. Would appreciate you citing the further 67% rule or acknowledging we were wrong about 100kB (or someone else with wallet2 experience chiming in, this probably is better for monero-dev though...)

<c​haser:monero.social> all the better!

<k​ayabanerve:matrix.org> I just got the quote from Cypher Stack for 70 XMR to review the latest work output by Veridise. I support that and jberman has also signed off.

<k​ayabanerve:matrix.org> I've also requested the next quote from Veridise for the final step of work regarding divisors and will go from there on that. The last discussion to further contract Veridise noted we were splitting the remaining work into two segments and only approving the first segment at the time.

<s​gp_:monero.social> Certainly interesting that the review is twice as much as the work output itself

<r​ucknium:monero.social> Do you want me to put that on today's MRL agenda?

<a​rticmine:monero.social> I will not be able to attend the MRL meeting today. Sorry.

<a​rticmine:monero.social> I am currently working on the scaling document.

<a​rticmine:monero.social> It will be based on the max 8 inputs and outputs, min 1 input and min 2 outputs specifications.

<o​frnxmr:monero.social> I don't want to ddos mrl meeting, but i want to clarify that feel we could do with a MAX_OUTPUTS of 2 and fix inputs to 2, 16*, 64* (* = debatable. But 8 is too low for a max)

<a​rticmine:monero.social> With respect to wallet maintenance I am strongly advocating for 100% clawback on the non power of 2 inputs and outputs. So 3 will have the same weight as 4 and 5, 6 and 7 will have the same weight as 8. This is applies independently to both inputs and outputs

<a​rticmine:monero.social> This breaks FCMP++, since we cannot have dummy inputs. I will also break scaling

<a​rticmine:monero.social> It will break scaling because of the very large transaction weights

<a​rticmine:monero.social> My proposal of 100% clawbacks will provide a powerful economic incentive for ongoing wallet maintenance to mitigate the impact of the max 8 inputs and outputs.

<k​ayabanerve:matrix.org> sgp_: The person who prior did the review left, so we have a bit of a loss in continuity unfortunately. I feel that's reflected in pricing.

<k​ayabanerve:matrix.org> Rucknium: Yes, though it is last minute, sorry.

<r​ucknium:monero.social> MRL meeting in this room in one and a half hours.

<o​frnxmr:monero.social> So inputs are 1-8? (1-2-3-4-5-6-7-8 are all options?)

<o​frnxmr:monero.social> What are the weights in layman's terms? I really don't understand how a 2/2 would compare to a 64/2 or an 8/8

gist.github.com/kayabaNerve/dbbadf1f2b0f4e04732fc5ac559745b7 says "15 ms" per one input. I assume it's the reference implementation and it's not the fastest possible.

<k​ayabanerve:matrix.org> sech1: Give me an optimized Helios/Selene and we ideally save ~50%.

I can do it (no jokes). I need to see the reference code, estimate what can be improved and allocate my time to do it.

<k​ayabanerve:matrix.org> sech1 github.com/kayabaNerve/fcmp-plus-plus/tree/develop/crypto/helioselene

<k​ayabanerve:matrix.org> It's replacing the generic arithmetic with a tailored implementation. The Crandall primes have a fast reduction we don't use at all.

<k​ayabanerve:matrix.org> I'm pretty sure the non-platforn-specific field arithmetic in Ed25519 is roughly twice as fast though I'd have to redo my benchmarks to double check. It may be the entire lib is roughly so fast and part of that would be the Twisted Edwards curve formulas.

<k​ayabanerve:matrix.org> There also may be some room to reduce the amount of allocations we do. If you want to get cursed and optimize to the limit, we generate the matrices per-proof. While the matrices do change with every proof, a large portion of them are consistent. I believe a single set of matrices cloned, then selectively populated with the variables, would also be faster. It's just a lot messier <clipped message

<k​ayabanerve:matrix.org> and difficult to audit so it doesn't have my endorsement for the reference implementation.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1116

<r​ucknium:monero.social> 1) Greetings

Hello

<c​haser:monero.social> hello

<s​yntheticbird:monero.social> hi

<j​berman:matrix.org> *waves*

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<k​ayabanerve:matrix.org> 👋

<r​ucknium:monero.social> me: Researching a response to a HackerOne vulnerability report. Updated my "Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis" to include a MAX_INPUTS = 128 analysis and *fixed a mistake in the computation* therein: gist.github.com/Rucknium/784b243d75184333144a92b3258788f6

<r​ucknium:monero.social> I add these two papers to moneroresearch.info in the FCMP subcategory: moneroresearch.info/index.php?actio…CORE&method=subcategoryProcess&id=1

<r​ucknium:monero.social> Slaughter, F., Goodell, B., & Salazar, R. (2024). "An Audit of the FCMP++ Addressing Protocol: CARROT."

<r​ucknium:monero.social> Bassa, A. (2024). "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points."

<k​ayabanerve:matrix.org> Finishing my work on the FCMP libs and trying to make clear the bounds we face.

<j​berman:matrix.org> Me: continuing locally building the FCMP++ tree on wallet sync, it's nearing completion (most recently got initial tests passing syncing a wallet from arbitrary height n on wallet restore)

<r​ucknium:monero.social> 3) CARROT audit/review: github.com/cypherstack/carrot-audit…ses/download/final/Carrot-final.pdf

<r​ucknium:monero.social> jeffro256: Do you have comments and/or summary of this?

<r​ucknium:monero.social> Maybe jeffro isn't available this meeting. In that case, I think we can defer discussion of this item until next week.

<r​ucknium:monero.social> 4) Proposed Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points". repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_27273

<r​ucknium:monero.social> kayabanerve: Do you want to start with this item?

<k​ayabanerve:matrix.org> Sure

<a​ck-j:matrix.org> Hi

<k​ayabanerve:matrix.org> There's not much to say beyond my messages prior to this meeting. It's review of the latest work output by Veridise. The review was prior done by Aaron Feickert @ Cypher Stack and is now being proposed to be done by F. Slaughter @ Cypher Stack, under the purview of Brandon Goodell @ Cypher Stack.

<k​ayabanerve:matrix.org> The rate quoted is 70 XMR. Considering review of this will require familiarization with the prior associated work, I find that acceptable.

<s​yntheticbird:monero.social> Me: Late update on the FCMP++ crate integration I haven't found the time to continue looking into it in the prior weeks and my schedule is still too tied in the future. I'm sorry but if someone want to take over the branch he is more than welcome.

<r​ucknium:monero.social> Anything noteworthy in the new Veridise document?

<k​ayabanerve:matrix.org> Proven security of the technique as we apply it, though the security of our application is the next (and final) step of work on this topic and is still being quoted.

<k​ayabanerve:matrix.org> This follows from the prior MRL meeting which contracted this work output. We decided to split the quote due to ongoing discussions over this latter part.

<0​xfffc:monero.social> ( my apologies everyone. I am on the road. So I am not going to be able to be online. My update is mostly PRs I have submitted past week. Fixing few minor issues. For next week I will spend most of my time on a optimization that I think will benefit monero-wallet-rpc ).

<r​ucknium:monero.social> What is the reason for reviewing this part now, compared to waiting until we have a larger whole to review all at once?

<k​ayabanerve:matrix.org> Pipelining?

<k​ayabanerve:matrix.org> This lets Cypher Stack use availability now on this, where that availability may otherwise be wasted.

<k​ayabanerve:matrix.org> It also reduces the latency for the full review.

<r​ucknium:monero.social> You said previously that getting new reviewers up to speed on the Veridise work will take time. I just don't want to have to get someone else up to speed for a second time.

<k​ayabanerve:matrix.org> It also enables finding errors in the current work product before moving on to the next work product. I am proposing running the two simultaneously, so I want to trade that benefit for overall efficiency, but finding errors midway through the next work product is still better than finding errors after the next work product.

<r​ucknium:monero.social> If you think scheduling is better this way, that's fine. I just wanted to bring it up

<r​ucknium:monero.social> Can we get more opinions on this proposed expenditure? In this channel before the meeting kayabaNerve said

<r​ucknium:monero.social> > I just got the quote from Cypher Stack for 70 XMR to review the latest work output by Veridise. I support that and jberman has also signed off.

<k​ayabanerve:matrix.org> Heard. I've not been happy with how this academic research has gone overall personally. I think we've always tried to make the best decision at each turn, and the academia itself is resolving as necessary/desired, but there's been much more paperwork (and costs) than desired/expected. That just still leaves me to try and make the best decision here, which IMO, is reviewing this now.

<v​tnerd:monero.social> Hi

Well, sounds just like living on the bleeding edge to me :)

Other people drive ambitious projects like this one right into the abyss

<s​gp_:monero.social> I just got a quote on the Veridise DLOG soundness proof, if we want to discuss that as well

<r​ucknium:monero.social> I don't really want to to to get MRL approval at this meeting because this was proposed publicly less than 24 hours ago. And previously I had suggested and kayabaNerve agreed that expenditure proposals should get a few days of MRL and community review. But I am willing to be convinced on this I guess.

<r​ucknium:monero.social> sgp_: Ok. Give a summary

<s​gp_:monero.social> [@kayabanerve:matrix.org](https://matrix.to/#/@kayabanerve:matrix.org) please confirm you're ok sharing this as well or if we need to have them fix something first. It's literally hot off the presses

<r​ucknium:monero.social> And for the Cypher Stack review, is there a write-up on the exact scope of the review?

<j​berman:monero.social> I +1 moving forward with CS on review for kayaba's reasons

<s​gp_:monero.social> I understand the extra review time to get caught up on the context, but I hope any further review (after being caught up) is more competitive

<j​berman:monero.social> Though it's worth nothing just reached out to another solid candidate we're waiting to hear back from. If that also doesn't work out, CS is a solid option

<k​ayabanerve:matrix.org> To be rude to Rucknium, I just received another quote and approval from jberman on it if we can discuss it today.

<k​ayabanerve:matrix.org> sgp_: Stop front-running me D:

<r​ucknium:monero.social> Like I said, I prefer to have more time to digest these quotes, so it is OK to bring them up now at this meeting to "start the timer".

<r​ucknium:monero.social> I would also prefer to have something written down in something more formal than a Matrix/IRC message

<r​ucknium:monero.social> When you can get such a thing written down

<r​ucknium:monero.social> So there are no misunderstandings about scope later

<k​ayabanerve:matrix.org> First, clarifying re: jberman: Someone potentially reached to volunteer their time in review. They were contacted specifically on this topic. I don't personally expect that to work out. I'd like to get the Cypher Stack quote approved regardless. We can leave it open in that either the CS quote goes through or the volunteer (at a cost of $0, so not needing MRL approval) will occur.<clipped message

<k​ayabanerve:matrix.org> I'll defer further commentary back to jberman.

<k​ayabanerve:matrix.org> Re: the newly received quote, it's 10-12.5k USD from Veridise for the resulting interactive protocol, the soundness proof, and finally verifying the specified R1CS matches. That follows the scope of work prior split off from the quote at the time we came to consensus on the prior quote.

<k​ayabanerve:matrix.org> Since it resolves the issues present in the quote when we split it off (allowing us to further discuss it and come to this quote), I find it amenable.

<k​ayabanerve:matrix.org> jberman also signified their approval.

<k​ayabanerve:matrix.org> Rucknium: I fully understand if this is too messy to discuss today and you want to kick this Veridise quote to next week.

So many things going on, one would almost want something like a flow diagram

<s​yntheticbird:monero.social> Github project maybe?

<k​ayabanerve:matrix.org> I mean, I'd prefer to keep the train moving, but I personally think this is quite messy to propose mid-meeting and absolutely won't contest kicking this to next meeting.

<s​gp_:monero.social> Fwiw MAGIC doesn't need a decision on the money today, I can sign with the hope of the money coming through as long as there's loose consensus it's a good idea

<r​ucknium:monero.social> Let's document the quotes in Gists or something. And that will make the mental flow chart easier

<s​gp_:monero.social> Waiting on the review for potentially free seems appropriate to me IMHO. At least a week or so

<s​gp_:monero.social> Unless there's a pressing blocker I'm missing

<k​ayabanerve:matrix.org> I also won't contest kicking Cypher Stack's review to the next meeting, especially given the commentary on a potential volunteer jberman brought up. I am not hopeful re: said volunteer but I acknowledge if this now exceeds the complexity allowed for time of prior awareness.

<k​ayabanerve:matrix.org> sgp_: If we have consensus, we have consensus and MAGIC will be promised the funds. If we don't have consensus, we don't have consensus, and if MAGIC funds this it's entirely on them.

<k​ayabanerve:matrix.org> I am not asking MAGIC to attempt to estimate loose consensus day and start making agreements.

<r​ucknium:monero.social> I'd suggest documenting the quotes in Gists or something. Please post links in this channel when you do. And we can discuss and hopefully approve a decision path next meeting.

<s​yntheticbird:monero.social> I know my talk don't have much value but with this many important items in the list maybe placing another meeting mid-week would be preferable

<s​yntheticbird:monero.social> There is always a few items that needs to be kicked at each meeting

<r​ucknium:monero.social> Maybe, if it keeps up like this. This is unusually busy and we have had meetings earlier this year that were pretty light

I think we must be near "peak FCMP++ reviews frenzy" and things quickly will get better

<r​ucknium:monero.social> People can of course discuss these things between meetings in this channel

<s​gp_:monero.social> I know MAGIC isn't promised the funds but I'm still happy to move forward immediately so there isn't a delay on the most important next piece of research, even if this channel might not approve it or need more time

<r​ucknium:monero.social> And we have the highly anticipated MAX_INPUTS/MAX_OUTPUTS discussion still on this meeting's agenda

<j​berman:monero.social> RE: Cypher Stack approval for review of Veridise work. I think this is a fairly clear solid route to take and it would be nice to arrive at loose conensus that would be the case today (just assuming the volunteer does not pan out)

<r​ucknium:monero.social> Let me ask rbrunner: Do you prefer that the Cypher Stack review of the Veridise document be approved today (after less than 24 hours notice) or to defer to next week's meeting?

I would say next week's meeting would be slightly better. Too many balls up in the air right now.

<r​ucknium:monero.social> Ok. It will go on next meeting's agenda. Thanks all. Sorry for the delay, but speed is the enemy of democracy, etc.

<r​ucknium:monero.social> 5) Discussion: preventing P2P proxy nodes. monero-project/research-lab #126

<c​haser:monero.social> can't we just form consensus between meetings if that would speed up the process?

<r​ucknium:monero.social> IMHO it would be good to decide on some actions. I think MRL should release a suggestion on Monero communication channels (Matrix/IRC, GitHub, monero.town, Reddit, Twitter, etc., maybe not necessarily the website blog) for node operators to run the IP address blocklist. Maybe some people can PGP-sign a hash of the blocklist.

<r​ucknium:monero.social> Then the second step could be for myself and possibly boog900 (and anyone else who wants to do so like vtnerd) to research the pros and cons of having an ASmap-like criteria for `monerod` establishing peer connections: monero-project/monero #7935

<r​ucknium:monero.social> I could start on step 2 in 1 -2 months probably.

<k​ayabanerve:matrix.org> ACK with frustration the first quote isn't being decided on this meeting but also understanding.

<r​ucknium:monero.social> chaser: Maybe, but I don't know what form that would take.

<s​yntheticbird:monero.social> Official communication would probably be the most effective solution in short-term, I don't see any reason not to do so now that the consensus has been reached on the seriousness of this network issue

Wow, the linked ASmap related PR waits since 2021?

<o​frnxmr:monero.social> Wouldn't asmap allow a large actor to: own multiple proxies on each provider, starving honest nodes of connections to other honest nodes?

<r​ucknium:monero.social> ofrnxmr: My research would investigate that question.

The way forward sketched by Rucknium sounds good to me. I thing without going into something like an "emergency mode" we don't have good alternatives anyway. Which is no problem IMHO.

<s​yntheticbird:monero.social> no there are more honest subnets than bad ones

<r​ucknium:monero.social> Basically, would an adversary gain an advantage in the status quo compared to more ASN diversity.

<c​haser:monero.social> I was thinking of something along the lines of the majority of the relevant (per competence) people signing off on it. I understand that's a loose definition, and that it may be difficult to reach everyone outside meeting hours (in which case it would be just carried over to the meeting). just an idea.

<r​ucknium:monero.social> It depends on the empirical distribution of honest nodes with respect to ASNs, which I have some preliminary results on

<o​frnxmr:monero.social> For home networks, but not for vps. Asmap makes vps a more attractive attack point imo

<r​ucknium:monero.social> OK I will write up a proposed communication plan on the blocklist for next meeting

<r​ucknium:monero.social> 6) Making transaction weight a function of number of inputs, outputs, and `tx_extra` length instead of number of bytes.

ofnrxmr: I think we mostly agree that this needs very careful research before any action

<r​ucknium:monero.social> kayabaNerve wrote up some more formal proposal on this here: gist.github.com/kayabaNerve/dbbadf1…732fc5ac559745b7#on-fee-calculation

<r​ucknium:monero.social> My question on this is how exactly do the confidential transactions arithmetic match up with the implicit fee rate.

<o​frnxmr:monero.social> I agree, as long as the tx sizes per input/output are relatively static.

<r​ucknium:monero.social> In bitcoin and its cousins, the fee is fully implicit: the fee is just the difference of the sum of outputs and inputs. But Monero does it explicitly since the sum of inputs and outputs isn't explicit due to CT

<r​ucknium:monero.social> By implicit/explicit I mean there is a field (or isn't) in the actual transaction data

<r​ucknium:monero.social> Ok we are beyond the hour and still have the MAX_INPUTS/MAX_OUTPUTS item. We can move on to that since there was a lot of interest in it

<r​ucknium:monero.social> 7) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS. On MAX_INPUTS and MAX_OUTPUTS. Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis.

<r​ucknium:monero.social> gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898

<r​ucknium:monero.social> monero-project/research-lab #100#issuecomment-2433524326

<r​ucknium:monero.social> gist.github.com/kayabaNerve/dbbadf1f2b0f4e04732fc5ac559745b7

<r​ucknium:monero.social> gist.github.com/Rucknium/784b243d75184333144a92b3258788f6

<r​ucknium:monero.social> Yes, there are four links associated with this item

<k​ayabanerve:matrix.org> Sorry, I had connectivity issues the past few minutes.

<r​ucknium:monero.social> IMHO, it may make sense to wait until there are actual CPU benchmarks for tx verification for these txs types before really getting into the discussion to make a decision. Consistent with what sech1 has said.

<k​ayabanerve:matrix.org> Re: topic 6, fee discretization, ArticMine already proposed an exact clawback to use.

<k​ayabanerve:matrix.org> On topic 7, my cited GH comment is deprecated by my long-form write-up. My Python estimator is deprecated by the actual Rust code which does now 100% accurately perform the size estimation (but is less accessible to work with).

I think we can indeed wait for hard numbers from actual benchmarks because technically the decisions do not seem to have too many consequences and interdependencies

(With emphasis on *technically* of course)

<k​ayabanerve:matrix.org> It's only the 1-input case I've extensively benchmarked. Additional inputs should be largely linear if we aren't discussing batch verification (such as upon mempool acceptance). 2-inputs double the base cost, and while they don't double the amount of commitments, those are a fraction compared to the base cost.

<k​ayabanerve:matrix.org> But ACK to providing more benchmarks. What exact FCMP params would people like to see?

<s​yntheticbird:monero.social> just to have a rough idea do you know what amount of commitment would represent the computation of one input ?

<k​ayabanerve:matrix.org> SyntheticBird: What?

Discussions seem to oscillate between max inputs of 4 versus max inputs of 8, right? So at least those two :)

<s​yntheticbird:monero.social> > while they don't double the amount of commitments, those are a fraction compared to the base cost.

<s​yntheticbird:monero.social> what fraction exactly (if known) ?

<k​ayabanerve:matrix.org> I'd refer you to the Python estimation code.

<k​ayabanerve:matrix.org> rbrunner: My advocacy is 8 for MAX_INPUTS at this time. I'm unsure anyone is advocating for 4. I've seen complaints 8 is too low but without associated recommendations.

<k​ayabanerve:matrix.org> (other than 8 is too low. My guess is the recommendation is anywhere from 16 to 120)

<k​ayabanerve:matrix.org> I don't believe anyone has called out reducing MAX_OUTPUTS to 8 though.

Just to be sure, next sensible step is 16, not 12 or even 10, for technical reasons?

(For max inputs)

<s​yntheticbird:monero.social> 120 isn't a power of two afaik

Not even if you squint?

<c​haser:monero.social> if the end goal is max 4/4, there will need to be a reduction anyway at a later fork. so, while max 4/8 sounds attractive, it's not necessary to achieve it with this fork.

<k​ayabanerve:matrix.org> The MAX_* values should be powers of two rbrunner

Thanks, thought so

Quite some step from 8 to 16 then

<k​ayabanerve:matrix.org> chaser: These changes aren't being made for uniformity.

<c​haser:monero.social> kayabanerve I know, but they still lead to a lower number of tx shapes, which does increase uniformity.

I tend to agree that a limit of 8 is a software problem for people with consolidation needs of large numbers of enotes, not a protocol problem

<k​ayabanerve:matrix.org> 2, 4, 8, 16, 32, 64 are all a reduction to MAX_INPUTS in effect and powers of two. I think even 16 is too much. I can have 1, 2, 4, 8, 16 benched to provide the data on that though.

<k​ayabanerve:matrix.org> 32, 64, by estimate, would be half a second and one second. Unless 16 surprises me by shattering my expectations, I'd argue those clearly unviable and not worth the time to collect data on.

<k​ayabanerve:matrix.org> We can phrase it as benchmarking until proof time exceeds some threshold though. Let me know the threshold.

Aren't 32 and 64 hardly viable on the grounds of transaction sizes anyway?

<k​ayabanerve:matrix.org> We currently support ~120. With a single aggregate FCMP, I'm pretty sure we'd be able to support 64 with current TX size limits.

<k​ayabanerve:matrix.org> I think we can even support 128. The issue is solely the verification time.

<k​ayabanerve:matrix.org> I did prior calculate the numbers on this, I'm just on my phone and can't pull them up now, sorry.

<s​yntheticbird:monero.social> blame the phone for being ergonomic enough for maths

<s​yntheticbird:monero.social> for not being*

<k​ayabanerve:matrix.org> It doesn't let me run my rust tests :(

<s​yntheticbird:monero.social> 😭,

<k​ayabanerve:matrix.org> Anyone, for what verification time threshold to run until?

<c​haser:monero.social> could be fit to the current protocol's times

<c​haser:monero.social> *fitted

<s​yntheticbird:monero.social> could it be possible? I thought it would be significantly higher than current RingCT.

<c​haser:monero.social> it may be, I am not sure of the current verification time per output

<k​ayabanerve:matrix.org> We can fit it to the current time for whatever the maximum amount of CLSAGs is.

<k​ayabanerve:matrix.org> cc jberman jeffro256 can one of you get me that number?

<j​berman:monero.social> Time to verify a 16 member CLSAG with max number of inputs?

<k​ayabanerve:matrix.org> Yes

I didn't have chance to reply about code optimizations until now, but what I can basically do is to polish an existing implementation and make it much faster. I'm good at it. As for the optimal implementation in terms of algorithms, that will require a much bigger effort from me, so better if kayaba prepares a reference with algorithms already

being optimal

<k​ayabanerve:matrix.org> Please and thank you

<k​ayabanerve:matrix.org> It's really just the time for one CLSAG scaled jberman

<c​haser:monero.social> I found a chart in the Seraphis paper that says 8 ms for 16 in

<k​ayabanerve:matrix.org> sech1: If I knew how to do this, I would've budgeted for it.

<c​haser:monero.social> wait, no. that's 16 ring size

<k​ayabanerve:matrix.org> Implementing tailored prime field arithmetic isn't in my repertoire sech1. It's why I used a generic bigint library. The point is to replace that with our own arithmetic, optimized add/reduce/mul algorithms, etc.

k​ayabanerve but you already mentioned some algorithmic optimizations which are possible

ah, I understand

<k​ayabanerve:matrix.org> The optimized algorithms depend on the primes we chose. Nicely, we only use 255 bits, not 256.

<k​ayabanerve:matrix.org> So that will enable certain algorithms which require access to that high bit. We don't need to allocate an extra byte for overflow.

<k​ayabanerve:matrix.org> But which algorithms? No clue. Not my field. I only know we chose a Crandall prime because it has a fast reduction algorithm.

<s​yntheticbird:monero.social> I think we can pardon you for not being knowledgeable on something at this point.

<j​berman:monero.social> Yea this has good benchmarks figures here: monero-project/research-lab #91

<k​ayabanerve:matrix.org> chaser: Is a single CLSAG with 16 ring members seriously 8ms per Seraphis paper?

<j​berman:monero.social> assuming you were looking at this chart for that 8ms figure: user-images.githubusercontent.com/3…09f-60e9-4be0-a18b-05e278567bc8.png

<k​ayabanerve:matrix.org> If so, you can craft TXs which take a second to verify rn which is cursed (though you find out if the current CLSAG is invalid on just an 8ms increment)

<c​haser:monero.social> kayabanerve if I get it right, yeah. 14 ms raw, 8 ms in 25 batches

<j​berman:monero.social> I think that chart is showing 4ms per CLSAG (since it's 8ms per 2-input tx)

<k​ayabanerve:matrix.org> CLSAGs can't be batch verified except perhaps a single operation?

<c​haser:monero.social> jberman yes, I was wrong. the chart is for 2/2's.

<k​ayabanerve:matrix.org> The TX time != the CLSAG time

<c​haser:monero.social> true. plot is thickening

<k​ayabanerve:matrix.org> I believe the meeting is all but called by Rucknium? I'll be withdrawing at the hour.

<c​haser:monero.social> is this it? eprint.iacr.org/archive/2019/654/1585584155.pdf#page=18 if so, then 15.9 ms

<j​berman:monero.social> Was just about to comment the same link :)

<k​ayabanerve:matrix.org> That's longer than an entire TX per Seraphis so it can't be 15.9 ms for a single 16-ring CLSAG. Either the software was improved or the hardware and we need to re-benchmark.

<c​haser:monero.social> hm. the 2.1 GHz Opteron they used may not be the most up-to-date benchmarking hardware.

<k​ayabanerve:matrix.org> I'll ask jeffro, who I'll also ask to run the benchmarks as they don't use VMs, to bench CLSAG so we have consistent reference hardware.

<s​yntheticbird:monero.social> 2.1 GHz Opteron is lowkey the most accurate reference for an inclusive implementation for normal people phone

<s​yntheticbird:monero.social> but i doubt people will run nodes on their phone

<s​yntheticbird:monero.social> i mean this isn't too far fetch, its low-power yes, but not unrealistic hardware

<c​haser:monero.social> that's good to know

<c​haser:monero.social> is it the case that mobile wallets verify the CLSAGs only for the transactions they receive, but full nodes verifies them for all transactions?

<j​berman:monero.social> mobile wallets don't verify CLSAGs AFAIK

<j​berman:monero.social> and yes full nodes verify them for all txs (except for CLSAGs before the node's highest hardcoded checkpoint by default)

<o​frnxmr:monero.social> I do

<s​yntheticbird:monero.social> im proud of you

<o​frnxmr:monero.social> My main node has run on my phone for maybe 3yrs now

<o​frnxmr:monero.social> Low power, battery backup (dont worry about corruption due to power flickers)

<o​frnxmr:monero.social> Main issue is storage. The device is 128gb and i'm running out of space fast :) (less than 1gb left atm).

<o​frnxmr:monero.social> anyway, offtopic. Just thought that i'd mention that nodes on repurposed phones are (imo) much more economical than running a desktop or purchasing a single board device etc

<k​ayabanerve:matrix.org> sneurlax is experimenting with building Cuprate into a phone app IIRC

Is there any easy way to increase storage on phones past 128gb?

<s​yntheticbird:monero.social> of course, with an sdcard destined to die in 6 month or a soldering station (don't forget to bring your chinese NAND chip with you)

so that's a no, then?

<s​yntheticbird:monero.social> what does no mean?