14:32:45 Reminder about this for the meeting today > <@sgp_> For the next meeting please: final approval (with CCS donation to MAGIC Grants) for zksecurity to review GBPs (with CS fixes) and the implementation. We have discussed this a few other times in the past with positive feedback. The review will start June 1. $100k 14:32:59 I have the full SoW and can answer questions about it 15:03:49 MRL meeting in this room in two hours. 15:18:26 @rucknium:monero.social and everyone: the CCS proposals repo/site does not seem to be up yet, so I don't know if we can make progress with ProbeLab's proposal. I'll join the meeting, but only an hour into the meeting (6pm UTC). Happy to discuss anything regarding the proposal then 👍️ 15:19:52 @yiannisbot:matrix.org: Thanks. Sorry for the technical difficulties. 15:30:56 we can at least see a recent snapshot of the proposal https://github.com/monero-project/meta/issues/1384#issuecomment-4389600333 15:35:14 I can free space space to revive it temporarily right when it's needed. Won't last long though. 16:42:09 moneromooo: What is needed to solve this issue 16:46:49 I am looking for a long term solution. 16:48:34 Either more disk, ongoing, since spam is slowly filling it, or a way to easily delete/prevent spam. 16:49:23 We're getting more disk in the presumably near future for now. 16:51:09 200 GB used now, the server's been up for at least half a dozen years I think. 16:51:53 Earliest directory is from apr 2918. So 8 years. 16:52:54 Also someone who knows how to use gitab and has time/inclination to maintain it, if the solution is to clean spam. 16:53:12 I used to manually kill spam in the very early days, but there are milloins of accounts now iirc. 16:53:12 So it has taken 8 years to fill 200 GB. How about an upgrade to say 2TB? 16:53:52 We're getting 1 TB at some point, says binaryFate, which should last a while, hopefully. 16:54:53 Would something such as POWER work here to deter spam? 16:55:42 I don't do sysop so I'm not familiar with antispam stuff. 16:55:42 Anubis or go-away might be useful there 16:56:34 I think spam comes from regular bots, nothing targeted so if we would customise Gitlab it would likely stop but I doubt anyone is interested in working on this, easier to just add more disk space and possibly delete some accounts 16:57:00 I would not place my bets on Anubis, as the one thing they try to prevent (large datacenters with hordes of GPUs scraping the hell out of your server) are precisely capable of solving Anubis challenges at effectively zero cost 16:58:52 We could do both. Add disck space to address the immediate issue and then look at options to address the spam issue. 16:59:07 Disk space 17:00:21 Meeting time! https://github.com/monero-project/meta/issues/1384 17:00:25 1. Greetings 17:00:33 Hi 17:00:36 Hi 17:00:41 Hello 17:00:42 Hi 17:00:51 Hello 17:01:12 Hello 17:01:49 Hi 17:02:32 waves 17:02:32

Hey 17:02:35 Hi 17:02:45 2. Updates. What is everyone working on? 17:03:11 Me: sal multisig wip 17:04:03 me: Jamtis 17:04:13 me: Helping with FCMP beta stressnet 17:04:16 beta stressnet, looking into GUI simple mode hard fork prep 17:04:50 Me: perf and unit testing the mempool patch for lws 17:05:22 It's otherwise merged with the new /feed code so it's just looking for buga at this pot 17:05:43 Hello, sorry I'm late 17:06:32 3. zksecurity review of Generalized Bulletproofs (GBP). 17:07:49 I think this can be a quick topic. I would like to get MRL research committee approval for a donation of $100,000 to review the composition and implementation of GBPs 17:08:32 Does this come from the FCMP research budget? 17:08:37 CS suggested changes to GBPs after finding an issue. This will evaluate those changes and resolve the outstanding items for them 17:08:45 @rucknium: yes, it would come from there 17:09:16 Not sure why to call this a "donation". Isn't it simply a payment? 17:09:25 Howdy 17:09:42 Will zksecurity just evaluate the changes or review the whole GBP? 17:09:51 whole shebang 17:10:35 > Note: The specification and the updated security proofs are in scope for review and not assumed to be correct. The goal is to ensure the correctness/security of the code, not just alignment with the "untrusted" specification. 17:11:29 Research fund currently has 597.89xmr, and owes $15k to CS for FCMP++ composition follow-up review (I'm not sure if this has been paid yet), so this would be a ways under half the remaining funds 17:11:49 At the current xmr price 17:12:02 Probably the term is "donation" since MAGIC is a nonprofit organization with legal status. 17:13:00 Discussion of this proposed expenditure? 17:13:19 I suspect legally it has to be a donation 17:13:21 I see. Just making sure it's not that a mysterious new donor suddenly appeared and left USD 100,000 behind :) 17:13:29 fwiw, this has been discussed in the past here multiple times, but it has been delayed after CS found issues with GBPs 17:14:58 I'm definitely a strong +1. I think it's clearly of critical importance to have this reviewed further, and bringing in another highly skilled independent team to do so makes strong sense to me 17:15:02 a review is necessary to safely use GBPs, a critical component of the FCMP++ upgrade 17:15:02 I did not follow closely, but I guess that finding of a problem by CS was a bit of a surprise, and thus a bit worrisome. I think it would be a good idea to become sure here. 17:15:56 I agree with @jberman:monero.social , @sgp_:monero.social , and rbrunner . 17:16:13 Any more discussion or objections to the proposal? 17:16:32 I agree 17:17:50 I see loose consensus in favor of zksecurity reviewing Generalized Bulletproofs (GBP) in exchange for the equivalent of 100,000 USD. 17:18:04 4. Audit of Helios/Selene Rust library. 17:18:15 Anything to discuss on this at the moment? 17:18:55 nope, other than if you are interested in submitting a proposal for this, please email justin⊙mo 17:19:23 5. Post-quantum encryption (https://github.com/monero-project/research-lab/issues/151#issuecomment-4281932714). 17:19:51 Quick update: Based on the last meeting, I decided to go with Option A for Jamtis and use the standard CSIDH-1024 parameters. The address length will be 400 characters. I'm working on an interactive payment protocol that will be able to provide full privacy without an on-chain key exchange (it will be an appendix to the address specs). 17:21:32 Not a fan of it being interactive - is that portion mandatory? The user cannot opt out of an interactive key exchange? 17:22:26 To clarify: there will be both options. A non-interactive PQ key exchange based on CSIDH-1024 and an optional interactive one based on symmetric crypto only. 17:24:19 Hmm. Symmetric crypto is a sure way to anger a QC 17:25:46 More noob questions from me, about scan time. What happens when an old-style (non-quantum-resistant) wallet scans a quantum-resistant output. Any slowdown? And the reverse: Any speedup when a new-style wallet scans a non-quantum-resistant output? 17:26:28 I don't really see another feasible route on the table here tbh. If we want mobile wallets to be able to restore a wallet from seed, then the more secure PQ key exchange algos don't seem practical by the figures here 17:26:35 A related question is how effective is parallel processing here? 17:26:56 The goal is for all transactions to have a CSIDH-1024 public key in tx extra. Legacy wallets will simply ignore the key. Scan times will be about the same as now for both legacy and Jamtis. 17:28:03 enote scanning is obviously parallelizable, but the amount of computation required makes CSIDH view tags infeasible 17:29:00 @jberman: @jberman:monero.social: Do you mean the interactive protocol or Option A for non-interactive? 17:30:02 That comment applies to both. I don't see another route on the table aside from those 2 routes: Option A for non-interactive, or the interactive protocol 17:31:33 What if we wait until better PQ algorithms are discovered? 17:31:51 I also think that option A and an additional interactive protocol is the best compromise. Addresses will remain usable and the interactive protocol can be used by users who want more PQ privacy than Jamtis will offer. 17:31:55 Hard to know what the future may hold, of course. 17:32:12 Waiting is not an option due to "harvest now, decrypt later". 17:32:42 At least with A we don't get astronomical scan times, with mobile wallets completely unable to scan themselves 17:34:23 It could theoretically be implemented and not deployed until the QC threat passes some threshold, and in that time if some better algo arises, perhaps we could swap it in 17:36:06 With Option A, a quantum adversary cannot identify all the outputs sent to an address that it does not know, correct? There would be limited ability to try to cluster the behavioral information. 17:36:15 but then there's n years of data to decrypt 17:36:25 As rbrunner mentioned last week (I think), making scan times infeasible for mobile wallets (basically, anything that would force you to self-host something like LWS) would eliminate a huge amount of people from being able to use Monero 17:36:54 In my opinion this is infinitely more of a UX burden than long addresses, for example 17:37:06 I think people could still use Monero. But would not be protected from a quantum adversary. 17:37:19 @rucknium: With option A, a QA can identify all outputs sent to any address sharing that one's view key. And it can identify spends in most cases 17:37:55 But not any outputs of a view key that it does not know any addresses of? 17:38:16 all ecdh and signing is broken by qc guys 17:38:20 It would ID spends because of change outputs sent to own addresses, I assume 17:38:21 you can't still use monero 17:38:28 @rucknium: Yes. but that is true of CARROT and legacy addresses too 17:38:44 rucknium: With option A, if the QA knows one of your addresses, they can calculate primary and secondary view tags, but can only probabilistically identify enotes to unknown addresses unless the address is reused. 17:39:26 jeffro256: No, it cannot identify spends. 17:39:42 If the adversary had the addresses of the sender and recipient, that would reveal the spending behavior fully. Not the amount. Correct? 17:39:48 Internal enotes use a symmetric key for view tags. 17:40:35 tevador: I mean that it can sometimes identify the spend location of external enotes, not internal enotes 17:40:49 I agree with Rucknium's comment of potentially waiting for more PQ options. Isogeny based scheme make me nervous. 17:41:14 If the adversary has Alice's and Bob's addresses, they can see enotes (without amounts) coming to Alice's and Bob's wallet, but can't infer they are transacting with each other. 17:41:47 if mallory has a and b addrs then mallory can get a and b sec keys no ? 17:41:56 jeffro256: It cannot, at least not for Jamtis enotes. 17:42:09 @luke:cypherstack.com: @luke:cypherstack.com: Thank you for your comment. Could you elaborate? 17:42:26 (Luke S is with Cypher Stack https://cypherstack.com/about.html ) 17:42:33 I guess he's talking about lattice etc problems 17:42:36 luke: I'm actually quite confident about CSIDH. 17:43:54 The original idea behind CSIDH is from 1996 IIRC, so fairly old. 17:44:46 Sure. Me and the other mathematicians have spent a great deal of time talking about PQ security stuff, both at CS and in our academic careers and it is the loose consensus that isogeny based problems are the least favorite of the potential PQ primitives. 17:44:52 > If the adversary has Alice's and Bob's addresses, they can see enotes (without amounts) coming to Alice's and Bob's wallet, but can't infer they are transacting with each other. 17:44:52 Maybe I'm remembering an attack which works on Seraphis, but not FCMP++ because of the key image composition. I'll look at it again. At least with Jamtis previously, if two enotes were spent from the same address, even if a QA didn't know the spend key extensions, they could tell that they were the same between 2 (one-time add [... too long, see https://mrelay.p2pool.observer/e/sJ6Pv4ALU1dNWmhh ] 17:45:50 It's been a while since I looked at that particular attack 17:45:58 Lattice based problems are fine but I personally am a big proponent of Code based cryptography. I think it is probably the most likely to retain its PQ status in the time to come. 17:46:56 jeffro256: IIRC that was a Seraphis-only attack, FCMP++ has perfectly hiding linking tags. 17:47:44 Seraphis also had perfectly hiding linking tags, though. The foil might be the hash-to-point in FCMP++ 17:48:30 luke: Yes, McEliece would have been great if it wasn't for the 250 KB public keys :) 17:48:50 A bit impractical for an address. 17:49:53 I agree, but it is entirely possible that we might see some sort of improvement in the near future. 17:50:32 Yes, but waiting means more exposed legacy addresses that will be broken and deanonymized. 17:52:32 tevador: for the non key exchange route, Tachyon may have a better set of tradeoffs worth considering as well I think 17:53:00 I'm not familiar with Tachyon 17:53:30 We should move on to the next item soon. 17:53:30 https://seanbowe.com/blog/tachyon-scaling-zcash-oblivious-synchronization/ 17:55:11 As I understand it, there's an always-on server that scans state without leaking privacy, and there's no key exchange protocol 17:55:54 6. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:56:16 We have forked! 17:56:17 Stressnet forked from testnet about 6 hours ago. 17:56:47 My monitors with charts are viewable at https://stressnetnode1.redteam.cash/ and https://stressnetnode2.redteam.cash/ 17:56:53 Cautiously awaiting bug reports :) 17:57:05 I am working on integrating FCMP++/CARROT wallet knowledge proofs into wallet2 today 17:57:50 AFAIK, other ways to view what's happening on stressnet are not available yet, e.g. onion block explorer and DataHoarder[m] 's alt blocks viewer. 17:58:08 I plan to get my block viewer up and running next week 17:58:14 $work has coincided and been quite busy 17:58:21 Thanks, DataHoarder ! 18:00:31 Anything more on stressnet? 18:01:31 nothing here 18:01:50 Stressnet discussion room is #monero-stressnet:monero.social or ``##monero-stressnet` on IRC. 18:02:01 7. CCS proposal: ProbeLab P2P Network Metrics Proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667). 18:02:57 can be accessed via this snapshot https://web.archive.org/web/20260502231314/https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 18:03:21 Thanks, plowsof . 18:05:19 Last time @sgp_:monero.social suggested "I think we need research on how dandelion++ works in an adversarial environment, with the presence of a community ban list that X% of honest nodes use and is Y% effective at fingerprinting adversarial nodes" 18:07:27 seems like a reasonable thing for monerosim 18:07:35 I wonder if there is much work involved to do that. The D++ paper showed, theoretically, that the recall that the adversary can achieve is p and the precision is p^2, where p is the percentage of spy nodes in the outbound connections of the targeted node(s). 18:07:59 monerosim could definitely be helpful with that, if it were to be done. 18:08:37 Also, the Clover paper empirically measured D++ efficacy with a closed bitcoind testnet. 18:09:17 im finding scale is the issue. though i guess it could just be 1 user sending transactions amidst a network of mostly monerods., not the 1k users (monerods and wallets) i for some reason have set the bar at 18:09:19 https://moneroresearch.info/222 Franzoni, F., & Daza, V. (2022). Clover: An anonymous transaction relay protocol for the bitcoin P2P network. Peer-to-Peer Networking and Applications, 15(1), 290–303. 18:09:40 Section 7.3, page 12 18:10:16 Measuring the effectiveness still does not solve the spy node issue, which is the ultimate goal. 18:11:06 Hi folks, back online and available now. Great there is a mirror for the proposal - I was not aware. 18:11:35 Can I assume that @boog900:monero.social does not want to comment about the proposal (or is just not checking pings in this room at this time)? 18:13:11 A simulation could discover a problem with monerod's implementation of D++ if it existed, however. AFAIK, there hasn't been a realistic test of the actual implementation. 18:13:50 Based on monerosim you mean? 18:14:16 Yes. monerosim would be the obvious platform for a test like that. 18:14:59 Code at https://github.com/Fountain5405/monerosim 18:15:31 Yeah, it could be a good first step. Although I think that a real-world test would help - maybe as a second step. 18:18:17 A few things that we've been thinking about regarding D++ are: if spy nodes can dominate or distract message propagation (before they're added to the ban list), what is the risk threshold of privacy guarantees for ban list adoption. I was also wondering what's the efficiency of "fluff timer" efficiency, e.g., if a malicious no [... too long, see https://mrelay.p2pool.observer/e/-cWJwIALYmZGdmc2 ] 18:18:40 But @rucknium:monero.social as you said, the spy node issues we've put in the proposal would come first IMO. 18:20:10 sorry to interject: The onion explorer rekt my blockchain. i think it might need to be updated for beta > <@rucknium> AFAIK, other ways to view what's happening on stressnet are not available yet, e.g. onion block explorer and DataHoarder[m] 's alt blocks viewer. 18:22:12 Sorry, I thought I had given some thoughts on it, but I don't support the proposal in its current form. I don't see that much value in a second network monitor. 18:22:12 I think we already have a pretty good idea of how D++ performs from the paper. I would rather research on how to stop spy nodes all together, maybe looking at how to further increase their costs. 18:23:14 Thank you, @boog900:monero.social 18:24:23 > we already have a pretty good idea of how D++ performs from the paper 18:24:24 What ratio of spy to normal nodes did the paper investigate? I can't remember. Is that close to what we found at: https://probelab.io/blog/peering-into-privacy-a-deep-dive-into-the-monero-network-topology/ ? 18:25:40 One important aspect of the spy node issue is the role of blockchain surveillance (BS) companies in setting up these spy nodes, and the use of spy nodes to obtain personally identifying information from wallet users by deceit. This was discussed in a leaked video. 18:27:00 @yiannisbot:matrix.org: they had graphs which plotted performance against fraction of spies 18:28:09 I am dressing the following comment from Ssgp_ : 18:28:12 @boog900: Sure, but can't remember what's the fraction they used. Will have a look. 18:28:16 More fundamentally, what is the important problem that this dashboard is going to solve? Why do we need one so much so that the community should crowdfund for one? 18:28:28 @yiannisbot:matrix.org: I don't know what you mean by your question. The theoretical formula works for any ratio of spy nodes. I looked at the D++ paper recently again. They used a modified bitcoind on bitcoin mainnet, but for tx propagation speeds instead of estimating spy resistance. The D++ paper had plenty of python simulations for numerical estimates for the spy effects, however. 18:28:55 @articmine: Exactly and that's why I think a risk threshold study would be important. 18:29:27 One of the key elements I see in this dashboard is publicly exposing the BS company behaviour 18:30:09 The Clover paper used actual bitcoind for a private testnet simulation to record the spy node effects (for Clover and D++). There is another paper that just did simulations that I will pull in a minute. 18:30:26 In my view both the study and the dashboard is needed 18:31:01 Sharma, P. K., Gosain, D., & Diaz, C. (2022). On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies. arXiv. https://moneroresearch.info/130 18:31:53 The Sharma, Gosain, & Diaz paper was about learning the private D++ graph. More complicated and difficult for an adversary to achieve. 18:32:54 I feel the result of any research on spy nodes is just going to be "spies bad". 18:32:54 Even if we say the privacy impact is 0, just the impact on the security of the network is enough to warrant research into how to prevent them. 18:33:17 so why not just skip to step 2 and work out how to get rid of them. 18:34:40 it would be cool to know that the spies probably got X% of tx origins, but what real value does that give us? 18:35:12 I shall end the meeting here since we are 30 minutes past the hour, but everyone should feel free to continue discussing any topic. 18:36:12 @boog900:monero.social: Would you suggest that research be put into something like this, but with fewer downsides? https://ieeexplore.ieee.org/document/10174897 18:36:16 I obviously feel that the dashboard would be valuable and I can't see anywhere the metrics we published on the blogpost, but happy to skip that part for now and proceed with Milestone 2 only for now. 18:36:46 The problem with open-ended research is that at the end, possibly nothing useful will come out of it. It's risky. 18:38:12 https://ieeexplore.ieee.org/document/10174897 citation is J. W. Heo, G. Ramachandran and R. Jurdak, "PPoS : Practical Proof of Storage for Blockchain Full Nodes," 2023 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), Dubai, United Arab Emirates, 2023, pp. 1-9, doi: 10.1109/ICBC56567.2023.10174897. 18:39:23 @rucknium: Do you refer to Milestone 2 of the proposal as open-ended? I would see a clear outcome out of it with recommendations and proof. 18:40:04 @yiannisbot:matrix.org: No. "work out how to get rid of them [spy nodes]" is the open-ended path 18:40:15 Yes I do think PPoS or something Proof-of-Storage-esque is going to be the solution for spy nodes > <@rucknium> @boog900:monero.social: Would you suggest that research be put into something like this, but with fewer downsides? https://ieeexplore.ieee.org/document/10174897 18:41:01 I asked the lead author of the D++ paper about how to get rid of spy nodes and she didn't have any great ideas. 18:41:35 That's in a previous MRL log from about a year ago IIRC 18:42:12 @boog900:monero.social: I agree with 18:42:12 > so why not just skip to step 2 and work out how to get rid of them. 18:42:12 I suggest that not only should we consider technical countermeasures, but social and even set the stage for legal countermeasures should one or more members of the community wish to go that route. 18:42:36 @boog900: If they still pay the full storage cost if we impl PPoS then we are out of options really, as they would have the resources to run real nodes. 18:42:49 This is an example of a research effort that did not produce the intended results: "Research to Defeat EAE Attack and Analyze Effectiveness of Churning Procedures" https://donate.magicgrants.org/monero/projects/eae_attack_and_churning 18:43:23 @boog900: At that point we would need to look at being a permissioned network, for tx-relay at least 18:43:44 Reasonably, PoW is probably out of the question because it would hit honest nodes too hard. 18:44:22 But cutting-edge research is often risky. 18:45:23 @rucknium: yeah I think so too 18:45:29 Yeah, it's tricky. 18:47:29 PoW might hit malicious nodes much harder than honest ones. Honest nodes: 12 outgoing connections. Malicious nodes: 1000 outgoing connections. 18:47:54 We have to consider that the adversary is likely very vulnerable to out of network countermeasures such as public exposure and the risk of legal action 18:48:38 spies use incoming connections for D++ 18:49:00 I think putting PoW for incoming would be a DoS right? 18:49:17 How do they get an incoming connection? By spamming the peer list. 18:50:05 If entering the peer list requires a PoW, it will be harder to spam. 18:50:21 They have a few nodes that make outgoing and spread the addresses of the many that just listen 18:50:51 that would be a 1 time cost though? 18:51:55 You can add a timestamp to the peer list and also hash the ID of the node keeping the list, so if they want to be included in 1000 peer lists, they need 1000x the PoW. 18:51:56 presumably this advisory has quite a bit of resources, I don't think we can give them enough compute to discourage them without impacting normal nodes. 18:52:34 My main point is that I would not dismiss PoW as a possible solution. 18:53:46 I am not so sure. The adversary is also trying to hide. I am not the biggest fan of user POW but this may be an exception. 18:55:15 POW is worth looking into as an option. Especially if we can reliably detect the spy nodes. 18:55:56 There are interesting differences between honest and spy nodes that can be targeted 18:56:21 jberman: I checked the Tachyon blog post. It seems that Zcash wants to eliminate non-interactive transfers, which is probably not what we want? 18:56:24 quote: "As a start, we'll be assuming that Zcash's future payment flows involve out-of-band payments where the sender and recipient use a separate channel for secret distribution." 18:59:56 So what I'm hearing is that it would be desirable to focus on Milestone 2 and consider some PoW aspect? 19:00:01 Or leave PoW out for a later stage? 19:07:07 @articmine: I agree. I think we can come up with better and more reliable heuristics. 19:14:29