15:05:45 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
17:01:45 <m-relay> <s​yntheticbird:monero.social> The legend once said that it was meeting time...
17:03:06 <rbrunner> Indeed
17:04:31 <m-relay> <s​yntheticbird:monero.social> 1. Greetings (unofficial)
17:04:48 <m-relay> <j​berman:monero.social> *waves*
17:04:51 <rbrunner> Here :)
17:04:53 <m-relay> <s​yntheticbird:monero.social> hello
17:04:54 <m-relay> <a​rticmine:monero.social> Hello
17:04:58 <m-relay> <c​haser:monero.social> hello
17:05:26 <m-relay> <s​yntheticbird:monero.social> 2. Updates. What is everyone working on?
17:06:39 <m-relay> <b​oog900:monero.social> ping Rucknium
17:06:50 <m-relay> <s​yntheticbird:monero.social> Rucknium:
17:07:30 <m-relay> <j​effro256:monero.social> Howdu
17:08:33 <m-relay> <s​yntheticbird:monero.social> I propose if rucknium isn't there at :10 we run a wheel to decide who is moderator
17:08:44 <m-relay> <0​xfffc:monero.social> Hi everyone. I am off. But I will be reading the meeting silently.
17:09:28 <m-relay> <j​effro256:monero.social> Me: PR reviews and improving the Carrot library flow
17:10:08 <m-relay> <c​haser:monero.social> SyntheticBird: you've already assumed that role :)
17:10:23 <m-relay> <s​yntheticbird:monero.social> alright if you insist chaser \* proceed to act shy \*
17:12:14 <m-relay> <a​rticmine:monero.social> I have been working on scaling algorithm  for FCMP. The consensus part is done. I am working on the fee part
17:12:14 <m-relay> <a​rticmine:monero.social> Reviewing the BCH scaling algorithm.
17:12:16 <m-relay> <a​rticmine:monero.social> I am also reading Highjacking  Bitcoin. Many assumptions there on both sides
17:12:50 <m-relay> <j​berman:monero.social> me: updated the FCMP++ WIP PR with the latest (includes wallet sync, improved tree build time, and a demo of calling prove/verify over the FFI. latest builds passing with @tobtoht's help): https://github.com/monero-project/monero/pull/9436
17:14:38 <m-relay> <s​yntheticbird:monero.social> 3. Prize contest to optimize some FCMP cryptography code.
17:14:47 <m-relay> <s​yntheticbird:monero.social> jberman:
17:15:04 <m-relay> <s​yntheticbird:monero.social> (tell me if im switching too quickly)
17:15:16 <m-relay> <j​berman:monero.social> good pace to me :)
17:17:28 <m-relay> <j​berman:monero.social> A list of tasks todo for the contest:
17:17:30 <m-relay> <j​berman:monero.social> 1) Write a test suite for the competition
17:17:32 <m-relay> <j​berman:monero.social> 2) Finalize contest specs/details
17:17:34 <m-relay> <j​berman:monero.social> 3) Decision on where to host the competition
17:17:36 <m-relay> <j​berman:monero.social> 4) How to accept submissions? (private or public)
17:17:38 <m-relay> <j​berman:monero.social> 5) Decision on how to raise funds
17:17:40 <m-relay> <j​berman:monero.social> 6) Who to get involved to judge the final submissions 
17:17:42 <m-relay> <j​berman:monero.social> 7) Decide on timeline/dates
17:17:44 <m-relay> <j​berman:monero.social> 8) Plan to attract talent
17:18:26 <m-relay> <j​berman:monero.social> Starting with 1, I'm happy to take a stab at this and will try to have a test suite ready by next MRL meeting (unless any takers want to give it a go)
17:18:57 <m-relay> <j​berman:monero.social> I figure we can discuss some of these details today, like 3/4/5
17:20:50 <m-relay> <j​berman:monero.social> On where to host the contest, could be as simple as a github repo, or create a new website. The latter would take more effort but would be nice to have in attracting talent. Here was a comparable contest site kayaba linked in a past meeting: https://www.zprize.io/
17:21:04 <rbrunner> Regarding 3): Maybe it's not glorious at all, but for exchanging info, progress reports, a simple GitHub issue could do
17:21:33 <rbrunner> Why a whole repo? So people can submit their code there?
17:22:28 <m-relay> <j​berman:monero.social> Ya, the repo could host the test suite as well, it would be clear how to submit code to win the contest by cloning the repo
17:22:46 <rbrunner> Alright
17:23:33 <m-relay> <j​berman:monero.social> ah I should also link kayabanerve 's exisitng draft repo for the contest: https://github.com/kayabaNerve/fcmp-plus-plus-optimization-competition/tree/main
17:23:37 <m-relay> <j​berman:monero.social> Can start from there
17:23:41 <m-relay> <j​effro256:monero.social> As for 4, if we're using something like a Github repo, we need to make sure that as the contestants are pushing code, that they can't see the others' code, so we prevent plagiarism
17:24:13 <m-relay> <s​yntheticbird:monero.social> Re 3): a website would only possible if people are available to make it (i'm not sorry), would need to ask at monero-website.
17:24:14 <m-relay> <s​yntheticbird:monero.social> Re 4): Allowing anonymous submission is always preferable.
17:24:15 <plowsof> having the code private - but confirmed test results public would prevent someone from running the attempt through an LLM and submitting a slightly different variation under an alias to claim any runner up prizes 
17:24:16 <m-relay> <s​yntheticbird:monero.social> Re 5): CCS as always?
17:24:47 <plowsof> although the people who submit attempts could still do that :) 
17:25:11 <m-relay> <j​berman:monero.social> ya, the runner up part seems tricky since it leaves room for gaming
17:25:31 <m-relay> <j​berman:monero.social> private submissions could be a patch to the repo submitted privately to an email
17:25:42 <rbrunner> A website for 3) would be cool, but well, we can't even move our "New GetMonero.org" forward, so ...
17:25:45 <m-relay> <j​berman:monero.social> anon submissions definitely should be allowed imo too
17:26:01 <m-relay> <j​berman:monero.social> repo sounds fine to me
17:26:41 <Rucknium> Hi! Sorry. Had unexpected problems.
17:26:48 <rbrunner> I think "making noise" in the right circles for the contest could be much more important than some nice website
17:27:34 <m-relay> <s​yntheticbird:monero.social> Hi Rucknium, we were at 3.
17:27:48 <m-relay> <j​berman:monero.social> anyone against a repo?
17:28:24 <m-relay> <a​rticmine:monero.social> Sounds to me like a reasonable approach
17:28:29 <m-relay> <s​yntheticbird:monero.social> same
17:28:31 <m-relay> <j​berman:monero.social> great
17:29:13 <m-relay> <j​berman:monero.social> anyone against private submissions via patch via email, feel free to speak up :)
17:29:40 <rbrunner> GitHub doesn't offer something there? Private repos that you can open for select persons?
17:30:40 <rbrunner> Maybe even if, too complicated
17:30:57 <m-relay> <j​berman:monero.social> so contestants fork the repo, keep their fork private and share with judge(s)
17:31:10 <m-relay> <j​berman:monero.social> seems reasonable. either would work
17:31:17 <m-relay> <j​berman:monero.social> on the decision to raise funds, there is also the general fund which ofrnxmr has voiced reasoning to utilize in the past. figure it's worth discussion compared to a CCS
17:32:21 <rbrunner> Hmm, maybe a CCS could already be a part of "making noise"
17:32:34 <m-relay> <s​yntheticbird:monero.social> If Core is willing to give GF should be better.
17:33:03 <m-relay> <s​yntheticbird:monero.social> rbrunner not sure, people external to monero may not care about CCS.
17:33:12 <rbrunner> Do we already have an idea of the sum that we might offer?
17:33:13 <m-relay> <s​yntheticbird:monero.social> it will just be a "Look we're crowdfunding our super context"
17:33:18 <m-relay> <s​yntheticbird:monero.social> contest*
17:33:56 <m-relay> <s​yntheticbird:monero.social> From the repo: 
17:33:58 <m-relay> <s​yntheticbird:monero.social> > The best submission for an optimized helioselene will be awarded 50 XMR. The second best submissions will be awarded 25 XMR.
17:34:00 <m-relay> <s​yntheticbird:monero.social> > The best solution for an optimized ec-divisors will be awarded 150 XMR. The second best submission will be awarded 75 XMR.
17:34:54 <rbrunner> That's a bit at the low end if you ask me ... If I compare how much we paid for specialist time for reviews and audits
17:35:05 <m-relay> <j​effro256:monero.social> Agreed
17:35:56 <rbrunner> Although it's always sooo easy to spend other peoples' money :)
17:36:20 <m-relay> <s​yntheticbird:monero.social> i'm sure general fund will do just fine
17:38:55 <m-relay> <j​berman:monero.social> How about 500 XMR for ec divisors 1st place (close to $100k), 200 XMR for helioselene 1st place? kayaba likely has greatest context into amount of work it might take for participants, so this is a bit stabbing in the dark. But it's also a fairly important element we very much so want to see optimized
17:39:57 <m-relay> <j​berman:monero.social> also, 2nd place getting half is definitely a lot when 2nd place could potentially be gamed by 1 participant with anon submissions
17:40:17 <rbrunner> If the GF can fund that, why not.
17:41:28 <m-relay> <c​haser:monero.social> if needed, I'm sure a CCS could fill in a funding gap. last year's CCS's proved that the community is more than willing to fund efforts to make FCMP++ succeed. we even had a private actor step up and fund research outside the CCS.
17:42:06 <m-relay> <j​berman:monero.social> it seems there is some rough support to request the GF to fund (or help fund) the contest as well. we can let that marinate until next week
17:42:14 <m-relay> <s​yntheticbird:monero.social> Perfect
17:42:21 <m-relay> <j​effro256:monero.social> How much XMR is estimated to be left over from the FCMP++  research fund?
17:42:22 <m-relay> <s​yntheticbird:monero.social> 4. Some preliminary results from [OSPEAD](https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html) research into improved decoy selection algorithm.
17:42:40 <m-relay> <s​yntheticbird:monero.social> Rucknium
17:42:57 <Rucknium> Attack success = correctly guessing the real spend in the ring.
17:43:12 <Rucknium> Recall that the theoretical minimum attack success through completely random guessing would be 1/16 = 6.25%
17:43:31 <Rucknium> According to my estimates, an adversary could take advantage of the divergence between the real spend age distribution and the status quo decoy distribution to achieve an attack success probability of 23.5%, on average, since the August 2022 hard fork. This corresponds to an effective ring size of 4.2
17:43:47 <Rucknium> With a new improved, fitted decoy distribution, we can get that probability down to 7.6 percent, corresponding to an effective ring size of 13.2
17:44:10 <Rucknium> What is the relevance of this after FCMP activation? There will be a _backup_ method to construct FCMP txs that requests the FCMP Merkle tree paths as a set of decoys from a (potentially spying) remote node. So this distribution can be used for that.
17:44:34 <Rucknium> I will probably publicly release all OSPEAD-related documents and code around February 20.
17:44:49 <Rucknium> At least one thing that I could use wider feedback on is how quickly do we think the ecosystem implemented the off-by-one patch. I tried to measure it statistically, but I got unsatisfactory results because the difference between the patched and unpatched distributions is so small.
17:45:06 <Rucknium> However, it is important to get it right since it affects the real spend estimate of the youngest spendable block, which is probably the most common block to spend from.
17:45:20 <Rucknium> Right now I just assume a linear trend from the date of release of the patch to the end of the dataset (now October 2024), assuming 75% adoption by the end.
17:45:36 <m-relay> <c​haser:monero.social> 4.2? damn. is that attack viable today? and what does such an attack take to execute?
17:46:14 <Rucknium> Yes, continues to be viable. Some weeks it would be even more efefctive, some weeks less. Depends on what the real spend age distribution is each week.
17:46:30 <Rucknium> To execute the attack you need an estimate of the real spend age distribution
17:47:04 <m-relay> <a​rticmine:monero.social> There is also the possibility of combining this with clustering algorithms
17:47:19 <m-relay> <c​haser:monero.social> alright, but how does an adversary arrive at a good estimate of the real spend age distribution?
17:47:27 <Rucknium> The larger the divergence between the real spend age distribution and the decoy distribution, the higher the attack success probability.
17:47:34 <m-relay> <s​yntheticbird:monero.social> jeffro256: according to CCS repo there is 1537 XMR left
17:47:50 <m-relay> <s​yntheticbird:monero.social> (continue on ospead)
17:47:53 <Rucknium> Through the techniques I developed in the OSPEAD research
17:47:57 <m-relay> <c​haser:monero.social> Artic: feel free to expand on clustering algorithms
17:48:32 <m-relay> <a​rticmine:monero.social> The best example is the leaked Chainalysis video
17:49:12 <Rucknium> This is why the estimate of the real spenddistribution is a double-edged sword. It would allow you to set a better decoy distribution, but it also allows an adversary to attack user privacy.
17:50:23 <Rucknium> The attack sucess estimate I quoted is about single-ring attack effectiveness. When a tx has multiple rings, the correlations between them can be leveraged.
17:50:26 <m-relay> <c​haser:monero.social> Rucknium: I see. and this potential attack will become publicly viable, retroactively, when OSPEAD is published, right?
17:50:55 <m-relay> <j​berman:monero.social> "according to CCS repo there is 1537 XMR left" -> working on an estimate for how much we expect to be leftover after all tasks completed
17:50:55 <Rucknium> There's a paper on MoneroResearch.info by Borggren about the inter-ring correlations.
17:51:10 <Rucknium> chaser: yes
17:51:44 <m-relay> <a​rticmine:monero.social> The co spend heuristic was used to overcome ring signatures of 16. The cluster has to be larger than the effective ring size. If one lowers the effective ring size to say 5 then the cluster size needed is much lower
17:52:06 <Rucknium> In fact it would not be difficult for me to write a bit of code to try to guess the real spend in all rings since August 2022
17:52:22 <rbrunner> What's the importance of the August 2022 hardfork? Just the start date of your investigation? Or something "wrong" since only that?
17:52:35 <Rucknium> Just the start date
17:53:32 <Rucknium> that jberman implemented
17:53:48 <Rucknium> No good reason to go back further than that, but you could
17:54:13 <Rucknium> It took about two weeks of computation time to do the two years of data
17:54:25 <Rucknium> On a 64 thread machine
17:54:31 <rbrunner> Hmm, wouldn't several decoy selection algorithms in use make things *more* difficult for an adversary?
17:54:57 <Rucknium> And that's after I sped up one of the main steps by 240x compared to the original implementation :D
17:55:28 <m-relay> <j​effro256:monero.social> Perhaps going back further, when ring size was small, would help the more recent results, since one could eliminate very old decoys from new rings when the spend is known-ish?
17:55:49 <Rucknium> rbrunner: exactly. 70% of my R&D was spend on solving the problem with multiple decoy selection algorithms being used in the wild.
17:56:13 <m-relay> <a​rticmine:monero.social> It has to be ideally statistically indistinguishable from the actual spend distribution
17:56:28 <Rucknium> Spending very old outputs is very rare, though
17:56:35 <m-relay> <j​effro256:monero.social> Fair
17:56:46 <m-relay> <a​rticmine:monero.social> The output selection algorithm.
17:57:10 <m-relay> <c​haser:monero.social> 4.2 is very bad, IMHO. a severe reduction in the effective privacy of ringCT transactions. this could be way less for the 2024 March suspected spam period.
17:57:50 <m-relay> <s​yntheticbird:monero.social> have more than 2 outputs and you are screwed
17:58:44 <m-relay> <a​rticmine:monero.social> I have to leave for another meeting. Will review the discussion late.
17:58:56 <Rucknium> Sorry it took this long, but MRL decided that a new decoy selection algorithm probably could not safely be deployed without a hard fork, so other near-term priorities were put ahead of the research frequently
17:58:59 <m-relay> <s​yntheticbird:monero.social> waves
17:59:38 <m-relay> <s​yntheticbird:monero.social> Rucknium: ack.
18:00:06 <rbrunner> I think we got it pretty right with priorities. E.g. looking at the spam wave more or less in real time was indeed important.
18:00:22 <m-relay> <s​yntheticbird:monero.social> We're near over the hour, last topic
18:00:26 <m-relay> <s​yntheticbird:monero.social> 5. Research on [Autonomous System (AS) peer connection rules](https://github.com/monero-project/monero/pull/7935) to reduce spy node risk.
18:00:56 <Rucknium> Like I said in the previous meeting, any devs or resaerchers that want to see the report before Feb 20 can DM me for a copy.
18:01:29 <Rucknium> I read four papers on Tor's resistance to traffic correlations at the AS level
18:01:45 <Rucknium> Since we're at the hour, I'll discuss them next meeting I think
18:02:12 <m-relay> <c​haser:monero.social> rbrunner: I agree.
18:02:13 <rbrunner> Sounds reasonable.
18:02:25 <Rucknium> My plan now is to figure out the cost structure that an adversary would encounter if they wanted to defeat an AS diversity rule by leasing IP addresses.
18:03:20 <rbrunner> Also something like a double-edged sword :) You do the budgeting for the adversaries :)
18:03:31 <Rucknium> Basically, is there a big discount from leasing many IP addresses from a single AS, compared to leasing many IPs from many ASes
18:03:44 <m-relay> <b​oog900:monero.social> FWIW I have been running my tool to find proxies and they are still running nodes on the banned IPs
18:04:05 <m-relay> <s​yntheticbird:monero.social> Probably because many don't have the ban list
18:04:07 <Rucknium> Thanks for the update, boog
18:04:08 <m-relay> <b​oog900:monero.social> "running nodes"
18:04:39 <m-relay> <s​yntheticbird:monero.social> """make it so that we can communicate with a node""" \* wink \* \* wink \*
18:05:01 <m-relay> <s​yntheticbird:monero.social> Alright is there anything someone wish to add ?
18:05:27 <Rucknium> Recently I emailed Fanti, the lead author of the Dandelion++ paper, asking her option on the Clover paper (D++ alternative) and countermeasures to node proxies. I'll share info when I have it.
18:05:52 <m-relay> <s​yntheticbird:monero.social> ack. thx for the efforts Rucknium
18:07:15 <m-relay> <s​yntheticbird:monero.social> We can end meeting there. Thanks everyone.
18:08:01 <Rucknium> Thanks for stepping in, syntheticbird :)
18:08:27 <m-relay> <s​yntheticbird:monero.social> np it boost my ego
18:09:14 <m-relay> <s​needlewoods:monero.social> you did a good job SyntheticBird, thanks everyone
18:13:08 <m-relay> <j​berman:monero.social> thanks all
18:15:41 <m-relay> <j​berman:monero.social> a comment Rucknium : the DSA would also be useful for the jamtis-RCT light wallet tier (so light wallets wouldn't need to download all elems necessary to re-build the tree), which imo should still be on the roadmap
18:19:32 <Rucknium> Good point :)
20:38:22 <m-relay> <j​berman:monero.social> Estimating 200 XMR for remaining EC divisors work, 50-200 XMR for gadgets formal verification (hand wave guess from other tasks), and 6 audits of varying complexity hand-waved at 50-200 XMR each also (perhaps more if we want multiple rounds). That's a pretty large range that could feasibly use the remaining fund of 1537 XMR. Seems unlikely that would occur and we'll likely end up <clipped message>
20:38:22 <m-relay> <j​berman:monero.social> with funds leftover, but I figure it makes sense to keep the XMR from the research fund reserved for the work drafted out in the CCS and not re-purpose it
20:44:17 <m-relay> <r​ottenwheel:unredacted.org> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) but this is not happening anymore because of forthcoming FCMP++ and CARROT network upgrade, correct?
20:46:26 <m-relay> <3​21bob321:monero.social> ^