<r​ucknium:monero.social> MRL meeting in this room in about two hours.

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

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

<o​ne-horse-wagon:monero.social> Hello.

<a​rticmine:monero.social> Hi

Hello

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

<k​ayabanerve:matrix.org> 👋

<k​ayabanerve:matrix.org> Managing academia, largely.

<j​berman:monero.social> *waves*

<j​berman:monero.social> continuing fcmp++ integration, opened a new CCS

<r​ucknium:monero.social> me: Finishing initial research on boog900 's transaction relay proposal: monero-project/monero #9334 . I will post it in a few hours. Also discovered that you can natively render LaTeX in GitHub comments now :D

<r​ucknium:monero.social> 3) Stress testing `monerod` monero-project/monero #9348

<r​ucknium:monero.social> 0xfffc has a WIP PR to implement dynamic block sync size: spackle-xmr/monero #26

<r​ucknium:monero.social> In the previous stressnet we encountered a limit when the block sync size was set to the default 20. Too much data in 20 blocks. Then we cut block sync size to 1 to be safe, but that's inefficient.

<0​xfffc:monero.social> Hi everyone. I am debugging the dynamic-bss algorithm. I will be absent from today's meeting. my apologies. ( if you want to take a quick look, you can find the code here: 0xFFFC0000/monero #35 )

<r​ucknium:monero.social> Stressnet is actually not being spammed right now. AFAIK, we will merge this dynamic BSS code plus the newest Monero release code and then start spamming to test it.

<r​ucknium:monero.social> Anything else about stressnet?

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. getmonero.org/2024/04/27/fcmps.html

<j​effro256:monero.social> howdy

<j​effro256:monero.social> that BSS PR doesn't touch the serialization limits, right?

<k​ayabanerve:matrix.org> GBP review is almost back (should have a shareable copy in a couple hours) and should be good to move forward with. It opened a new topic on quantifying security, former and upcoming, which may be worth spending the time on.

<0​xfffc:monero.social> 1. Not directly. But indirectly can user have huge values for their BSS size.

<0​xfffc:monero.social> 2. Serialization limit proposal is here and approved ( monero-project/monero #9433 ). Although obviously extra reviews can help.

<r​ucknium:monero.social> Quantifying security meaning N-bit security?

<0​xfffc:monero.social> "New serialization limit" I should say.

<k​ayabanerve:matrix.org> Goodell did the GBP review and raised this note, so they'd be an obvious candidate to do such work, yet I believe they're unavailable. Considering we in general don't have researchers to spare, I'd kick the work to the backburner.

<k​ayabanerve:matrix.org> Rucknium: Yes, there's a question of if on paper, we should be using 700-bit elliptic curves even today.

<k​ayabanerve:matrix.org> The security of GBPs should follow BPs and shouldn't aggravate the problem though.

<k​ayabanerve:matrix.org> And that 'on paper' number is largely worthless. The open question was raised for more precise quantification however.

<k​ayabanerve:matrix.org> So it isn't in any way a delay to GBPs and their deployment.

<k​ayabanerve:matrix.org> Once that's published, we can move forward with auditing the GBP crate I wrote? I believe that's ready and I'll commit my final touches.

<k​ayabanerve:matrix.org> The divisor review by CS came back. I forgot if we discussed that. The technique itself holds. Aaron was concerned about the method of taking the logarithmic derivative being unspecified *and* the lack of an exact proof being specified premised on the technique.

<k​ayabanerve:matrix.org> I did specify an exact proof, somewhat. I wrote out the exact R1CS gadget, defined how it's instantiated, etc. That was part of Veridise's work conducted while Aaron reviewed the technique itself.

<k​ayabanerve:matrix.org> Veridise did share their review with me, as it stands. It correctly takes the logarithmic derivative per their confirmation, and is secure, except for an open question on how I handled some variables.

<k​ayabanerve:matrix.org> The technique assumes all variables are positive. That definition loses meaning over a prime field. Numbers are [0, p). The best definition would likely be [0, p/2]? But even that is largely meaningless.

<k​ayabanerve:matrix.org> So the next step re: Veridise would presumably be to have them respond to Aaron's review, expand on variables being 'positive' when applied to a prime field (expanding the security proofs as necessary/clarifying them), and update their review of the gadget itself.

<k​ayabanerve:matrix.org> Then to kick that back to Aaron.

<k​ayabanerve:matrix.org> I'll also note I personally consider the technique being proven yet the application of the technique being questioned the first hitch in this academic process, and effectively a perfect exemplification of Aaron's concerns.

<k​ayabanerve:matrix.org> cc Aaron Feickert: who I forgot to ping, sorry.

<k​ayabanerve:matrix.org> I'm still discussing hours and timeline with Veridise to get the quote there. The MRL prior approved a limited set of extended hours (I believe bringing Veridise's total approved expenditure up to ~15k). I'm unsure how those hours have been exhausted.

<k​ayabanerve:matrix.org> We can get the quote and discuss it at the next meeting or continue discussing approving extended hours. I'll also contextualize even with this discussion, I believe Veridise is still less than the other quotes we received. I don't have an inclination either way as I don't like how handwavy I'm being and not having the firm numbers in front of me.

<k​ayabanerve:matrix.org> TL;DR 1) GBPs should be able to move to auditing. 2) Divisors had a hitch in conversion to a proof we're following up on.

<r​ucknium:monero.social> So Veridise would be asked to create a new proof of a new proposition or repair a proof?

<k​ayabanerve:matrix.org> I've also now asked 3 researchers regarding investigating our HtP to no success yet.

<k​ayabanerve:matrix.org> That summarizes research, can hand over to jberman for development.

<r​ucknium:monero.social> HtP = Hash-to-point. The one that exists now on mainnet

<k​ayabanerve:matrix.org> I don't know if they'd provide the necessary commentary on why integers over a prime field qualify as positive, or if they'd remove the bound on it being positive.

<k​ayabanerve:matrix.org> I discussed the work with Veridise's researcher and they seemed to enjoy the work and want to continue, and also believed (with their initial thoughts as a fallible person) it'd be resolvable.

<k​ayabanerve:matrix.org> I do support their continued engagement. Their researcher has an extensive track record regarding fields, and their rates have been solid, so I do think they're still the best fit.

<k​ayabanerve:matrix.org> And yes, sorry for the unexplained acronym.

<r​ucknium:monero.social> "We can get the quote and discuss it at the next meeting or continue discussing approving extended hours. " Is this something to discuss at this meeting? I don't know the difference between these two options.

<k​ayabanerve:matrix.org> If y'all agree it makes sense to continue the work, and want to approve *some* hour extension even though I don't have the details on it, that'd be at this meeting.

<k​ayabanerve:matrix.org> If we want to quantify the expected extension, current used hours, running total, and new total (upper bound based on hours), I need to wait for their updated quote.

<r​ucknium:monero.social> Maybe state a reasonable limit now and we can get loose consensus for that limit. If the new "quote" exceeds the limit, then come back next meeting

<k​ayabanerve:matrix.org> I think the latter feels better but I also don't think there's a practical issue with the former and it may get things dome a few days faster, but eh, a few days isn't the end of the world.

<k​ayabanerve:matrix.org> Setting a limit on our end so we do properly quantify it, despite the unknown quantities, also works out.

<r​ucknium:monero.social> Although no one else is talking so it's hard to measure loose consensus :)

<k​ayabanerve:matrix.org> I'd expect 5-10k to be the scale of extended work.

<j​effro256:monero.social> Most of this stuff is over my head, I don't know how to evaluate how much this work should cost ;)

<j​effro256:monero.social> How much of the original CCS fund has been exhausted BTW?

<k​ayabanerve:matrix.org> Though I'll practically note 10k, that upper bound, may put us a few k past Cypher Stack raising the question of if we could've gotten more affordable work by choosing them originally. I think that depends on if Aaron would've done the work successfully to this depth, and if work was kicked back to me on issue, it was graced into the existing work without additional cost. Somethin<clipped message

<k​ayabanerve:matrix.org> g to potentially consider in the future, despite our inability to change the past.

<k​ayabanerve:matrix.org> I also don't regret it as Aaron has done the review and if we didn't have Aaron do the review, we'd need another entity for that purpose which... would've been back to Veridise?

<k​ayabanerve:matrix.org> I'll pull up how much of the CCS has been exhausted... I believe less than or about half.

<j​effro256:monero.social> Without knowing too much about the depth of work, 10k is a reasonable enough extension...

<k​ayabanerve:matrix.org> Initial GBP review was a separate CCS

<k​ayabanerve:matrix.org> GBP review by Goodell - still pulling up the amount

<k​ayabanerve:matrix.org> Veridise on divisors - ~15k USD

<k​ayabanerve:matrix.org> CS on composition review @ 198 XMR

<k​ayabanerve:matrix.org> CS on divisor review @ 38 XMR

<k​ayabanerve:matrix.org> That's the only scopes done under this CCS at this time. We haven't moved to code audits.

<j​effro256:monero.social> I did have a gut feeling that Veredise might have underestimated the work somewhat given the disparity of the quotes, but it seems like they have been doing good work thus far

<k​ayabanerve:matrix.org> So I'd have to ask sgp_: how much XMR they received for the 10k USD initially for Veridise.

<k​ayabanerve:matrix.org> Goodell was 20-24k USD.

<k​ayabanerve:matrix.org> So 40k USD liability and 240 XMR of 2000 XMR raised.

<k​ayabanerve:matrix.org> *236 to be specific.

<s​gp_:monero.social> MAGIC's current balance for an audit program is $5,151.73, though I believe I am waiting on an invoice from Veridise

<k​ayabanerve:matrix.org> 300 grand if 150 a XMR, now just 225 grand. We have only spent 25% of the CCS.

<k​ayabanerve:matrix.org> sgp_: I was asking the XMR quantity you received for the 10k USD MAGIC handled.

<s​gp_:monero.social> 70 I think? I need to check

<r​ucknium:monero.social> IMHO, 10K USD to Veridise would be acceptable, but 5K is more reasonable since AFAIK they are sort of fixing a hole in the original work.

<s​gp_:monero.social> yes, MAGIC received 70 XMR

<k​ayabanerve:matrix.org> In that case, 306 XMR spent with a ~27k USD liability.

<k​ayabanerve:matrix.org> I'll keep 10k as the upper limit approved, barring objections here. I'd like Veridise in total to still be cheaper than other quotes we received so I'd try and keep notably under that.

<j​berman:monero.social> On the alternative of having gone with CS from the start: to be clear you're saying CS may have caught this issue (this issue that Aaron identified reviewing the application of the technique) that Veridise did not, and so it may have made sense to go with CS from the start?

<k​ayabanerve:matrix.org> Another candidate, who provided a flat quote, may have successfully performed and upon noting the positive bound didn't enable a proof in practice, removed that bound successfully.

<k​ayabanerve:matrix.org> If Veridise's work ends up more expensive than the flat quotes we received as we pay by the hour for this unexpected edge, then yes, for this work it'd have made sense to go with a flat quote (assuming their success).

<k​ayabanerve:matrix.org> Though again, Veridise would then become the candidate for proof review so the quotes for review would change. It's impossible to comment in totality.

<k​ayabanerve:matrix.org> I'm just being mindful of this position and trying to be responsible about that it.

<j​berman:monero.social> Got it. Sounding like a natural review process to me. 10k seems a reasonable upper bound to me, especially considering that's still within the ballpark of the altnerantive quote

<r​ucknium:monero.social> Hopefully Veridise aren't reading this chat and know our exact negotiation limits :P

<k​ayabanerve:matrix.org> To be clear, Aaron's review was there was a lack of a proof provided by Veridise. That was because I provided a proof. When they moved to reviewing my proof, they didn't mesh seamlessly, creating this hitch.

<k​ayabanerve:matrix.org> We already have an hourly rate. I'm not saying it's static across the now months we've been working together, but them changing their rates would be explicitly discussed.

<k​ayabanerve:matrix.org> *When Veridise moved to reviewing my proof

<r​ucknium:monero.social> I think we have loose consensus to go forward if their quote is 10K USD and below. If above, then bring the quote to the next MRL meeting.

<r​ucknium:monero.social> 5) Confirm next meeting agenda

<r​ucknium:monero.social> I want to ask if boog900 , 0xfffc , and vtnerd want to discuss possible next-generation transaction relay protocols for Monero next MRL meeting, especially this proposal: monero-project/monero #9334

<r​ucknium:monero.social> Or another meeting date is OK too. Or never, but that's not as good ;)

<0​xfffc:monero.social> ( quick update: I am close to finishing BSS PR, final testing right now. Once finished, I will work on 9334 full capacity. )

<r​ucknium:monero.social> Maybe MRL should discuss if issue #9334 is a good idea first :D

<r​ucknium:monero.social> IMHO, it has some privacy issues that might be fixed by injecting some noise

<a​rticmine:monero.social> This broadcast proposal is critical for determining bandwidth propagation limits for scaling

<a​rticmine:monero.social> Limiting unnecessary tx broadcasts

Kayabanerve 70 from ccs to magic

<0​xfffc:monero.social> In my opinion it is critical too. Bitcoin is using it right now IIRC.

<0​xfffc:monero.social> ( approach similar to 9334 )

<r​ucknium:monero.social> Yes there is a lot of wasted bandwidth now. Adding some "pull" methods can allow an adversary to query a node's transaction pool.

<0​xfffc:monero.social> I am sure there are some defensive mechanism for that. I have to look at the literature.

<r​ucknium:monero.social> I already have. That's the comment I will post in a few hours

<r​ucknium:monero.social> The comment is about where the risks come from (black hole attack scenario and network topology learning) and what some of the options are.

<r​ucknium:monero.social> We can end the meeting here.

<0​xfffc:monero.social> Great. Thanks :)

<a​rticmine:monero.social> Thanks for hosting

<b​oog900:monero.social> Rucknium: yeah I would be happy to discuss that next meeting, I'm waiting for your comment on 9334 but FWIW 9334 does not make the problem worse, we already have methods to directly query a nodes pool + some other methods that allow it as a side effect.

<b​oog900:monero.social> IMO we shouldn't delay work on 9334 when we are still exposed to this attack vector.

<b​oog900:monero.social> I have also been thinking about ways we can stop peers from using the new messages in 9334 to query a nodes pool, and one way would be to send a 1 byte random token with the tx hash and require this same token to be sent when the tx is requested

<b​oog900:monero.social> Slightly more data would need to be sent but still a lot better than the current protocol

<r​ucknium:monero.social> boog900: Yes, those existing methods could be modified

<r​ucknium:monero.social> Maybe it could be rushed, but is that necessary? Have all the options been evaluated? Will more technical debt be created if #9334 is implemented, then a better way is discovered?

<r​ucknium:monero.social> Probably it would be good to have the next generation relay protocol ready for the next hard fork.

<r​ucknium:monero.social> The bandwidth could be cut in half without new methods by setting a maximum limit on the connection fluff timer. If above the 50 percentile, then don't relay.

<r​ucknium:monero.social> I don't think that's a good long-term solution, but it's just another option

<b​oog900:monero.social> To completely remove this attack vector would not be a small task IMO

<b​oog900:monero.social> Rucknium: do we have numbers on how knowledge of the P2P graph affects D++ stem stage

<r​ucknium:monero.social> Yes

<r​ucknium:monero.social> Section "How much does p2p network topology discovery help an adversary link a transaction to an IP?" of my monero-project/monero #9218#issuecomment-2260917643

<r​ucknium:monero.social> Actually some of the D++ paper's graphs are hard to interpret since their scales have just one labeled tick

<r​ucknium:monero.social> and they are log-scaled

<r​ucknium:monero.social> So I tried my best to use eyeballs. Their simulation code is open source on GitHub (recently updated for Python3) so we could re-run a lot of that

<b​oog900:monero.social> Fig 3 is made with knowledge of the anonymity graph right?

<b​oog900:monero.social> anonymity graph = exact 4-regular

<b​oog900:monero.social> graph in this case

<r​ucknium:monero.social> IIRC, the Max Weight estimator is what the adversary would use if it knows the p2p graph

<r​ucknium:monero.social> I think knowing the private subgraph (4-regular) or the p2p wasn't completely clear from how they explained it, but later in the paper it looks like they mean knowledge of the p2p graph

<b​oog900:monero.social> `On the other hand, if a 4-regular graph is unknown to the adversary, it has a precision very

<b​oog900:monero.social> close to that of line graphs (orange solid line in Figure 3). But if the graph becomes known to the

<b​oog900:monero.social> adversary (orange dotted line), the increase in precision is smaller. At p = 0.15, the gain is 0.06—half

<b​oog900:monero.social> as large as the gain for line graphs. This suggests that 4-regular graphs are more robust than lines

<b​oog900:monero.social> to adversaries learning the graph, while sacrificing minimal precision when the adversary does not

<b​oog900:monero.social> know the graph.`

<r​ucknium:monero.social> Ah. Hm. I was looking at appendix C too.

<b​oog900:monero.social> I think C is also talking about knowledge of the anonymity graph:

<b​oog900:monero.social> `However, Figure 15 illustrates the average precision for an adversary that

<b​oog900:monero.social> knows both the graph and the internal routing decisions of each node. Here, the trend is reversed:

<b​oog900:monero.social> line graphs have a precision that is upper bounded by p, whereas on 4-regular graphs, the precision

<b​oog900:monero.social> can be higher than p. This makes sense because on line graphs, each node has only one possible

<b​oog900:monero.social> routing decision, so the additional routing knowledge of the adversary does not help.`

<r​ucknium:monero.social> I think you could be right. I was thinking they were talking about the overall p2p graph since their earlier paper of bitcoin diffusion analyzed what additional accuracy an adversary could get from knowing the p2p graph. So maybe the D++ paper doesn't analyze how an adversary could use the overall p2p graph to de-anonymize the stem phase.

<r​ucknium:monero.social> At the end of Appendix C, they say that an attack to learn the routing dicisions (deeper knowledge than just the 4-regular graph) is very expensive. Basically Sharma, Gosain, & Diaz (2022) took that as a challenge and developed an estimator and simulations of how to learn the 4-regular private subgraph moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=130

<r​ucknium:monero.social> Sharma, Gosain, & Diaz (2022) needed to create an unreasonable (IMHO) large number of transactions per node to estimate the private subgraph. AFAIK they needs the overall p2p graph first to run their estimator.

<r​ucknium:monero.social> But knowledge of the p2p graph still helps an adversary that black holes a transaction since honest node(s) in the preceding stem path go into fluff mode.

<r​ucknium:monero.social> There are other attacks that use knowledge of the network graph like 0-conf double spending, partitioning, and eclipse. (But some researchers think these attacks are hard to execute anyway.)

<r​ucknium:monero.social> Granted, those same researchers said "please use our new protocol that makes the p2p graph public, because those possible attacks aren't so bad."

<r​ucknium:monero.social> Same researchers that suggested the Clover protocol as an alternative to D++

<r​ucknium:monero.social> I'll revise my comment on PR #9218. Thanks for catching my misinterpretation, boog900

<0​xfffc:monero.social> ( I skimmed this last week. Basically very similar to dandelion++. I didn’t see a substantial redesign. )

<b​oog900:monero.social> ehh it is different, from routing txs from inbound peers to other inbound peers and vice versa for outbound peers.

<b​oog900:monero.social> My initial thoughts are it probably is an improvement from D++ given that peers that don't accept inbound connections are not useful for D++ but I agree with Rucknium that they did not do as deep a dive as the D++ paper.

<b​oog900:monero.social> according to the clover paper only 10% of the Bitcoin network is reachable