17:04:37 Meeting in a bit less than 1 hour 18:00:03 Meeting time. Hello! https://github.com/monero-project/meta/issues/1198 18:00:18 hello 18:00:32 hey 18:01:54 Hi 18:02:21 👋 18:02:36 Ok, let's start already with the first reports 18:02:51 After studying code for quite a while and an extensive discussion with Rucknium I am ready to start coding modifications of the peer selection mechanism 18:03:50 Howdu 18:04:34 I tried to catch up a little with the fcmp++ development and looked into the fcmp++stage branch and cli/rpc wallet integration 18:04:45 *waves* 18:05:09 me: shared tx weight analysis, fixed a bug in the wallet tree cache, worked on moving forward outstanding PR's, pushed a draft PR demonstrating memory safe FFI usage (https://github.com/seraphis-migration/monero/pull/39), this week working on removing the FCMP++ input limit for the alpha stressnet May 21st (we seemed to have solid support in favor of PoW-enabled relay for larger i nput txs >8 so that nodes don't expose a vector to hog CPU verifying invalid FCMP++'s) 18:05:12 Same update as rbrunner7 , but from the other side of the table. There are a few open questions, but they will probably be resolved without much trouble. 18:05:50 "we seemed to have solid support in favor of PoW-enabled relay for larger input txs >8 " interesting development 18:06:06 me: fixed a few bugs with Carrot/FCMP CLI/RPC integration and am working on GUI integration 18:06:32 (solid support *in last MRL meeting* in favor of PoW-enabled relay) 18:07:12 Was that in the MRL meeting itself? Maybe I checked out too early ... 18:07:50 Ah it might have been in the convo right after, spillover from the meeting 18:08:02 Do we have a candidate for the PoW algorithm already? That stuff that tevador did for Tor? 18:09:00 perhaps the low memory RandomX variant makes sense for this use case: https://libera.monerologs.net/monero-research-lab/20250430#c522764-c522767 18:09:27 Ah, yeah, one new dependency less if that fits the bill 18:10:40 That may mean that some smartphone wallets won't bother and not offer txs with more than 8 inputs ... 18:10:51 But I guess can't have it all 18:12:18 Likely the only reason they might not bother is if they don't want the RandomX dependency. Preliminary discussions on expected CPU-time for the PoW will be fairly light relative to tx construction in the first place 18:12:53 Maybe that's a bit of a heresy, but maybe a quick look over to what Nano did? Feeless, network stability and spam protection entirely based on PoW, as far as I remember. 18:13:21 Or they may not want it if they are very RAM size constrained i.e. less than 256MB 18:13:54 IIRC, their PoW-only solution was successfully attacked. Then they added tx prioritization by amount and age, which Monero hides. 18:13:54 Tobtoht didn't want RandomX simply b/c Windows Defender is stupid and flags everything with RandomX in it as malware 18:14:22 would be pretty surprised if there's a wallet out there that implements scanning the chain with less than 256mb 18:14:26 They have a point ... 18:15:04 I think it is safe to assume people willing to execute transactions with phones or low-memory devices are unlikely to use more than 8 inputs 18:15:12 Really? Doesn't wallet only queue 10 blocks at a time? 18:15:27 *wallet2 18:16:14 Oh wait I'm thinking of the async scanner, and it's requests, not blovks 18:16:16 SyntheticBird: I guess it may happen "just like that", depending on the enotes that are present, and their values 18:16:18 IIRC, people have done pool mining to hardware wallets and then wondered why their triple-digit-input txs couldn't be signed 18:16:29 Cool 18:17:03 Lol 18:17:20 lmao fair 18:18:28 the daemon currently has a max cap of 100mb OR 20k txs OR 1000 blocks, whichever comes first. Then wallet2 is doing some copying, sooo.. it's feasible to sync with less than 256mb of ram, but would be pretty surprised if anyone's actually doing it 18:19:55 good point 18:20:34 jeffro256: Did you already schedule what comes after GUI wallet? I guess not much big stuff is left now. 18:20:37 https://support.ledger.com/article/360018969814-zd 18:20:38 > Sending a large number of transactions to a Ledger hardware wallet is troublesome. If you receive a lot of small transactions from mining please read this article carefully. 18:21:41 "since the chip may overheat" Mmmm, ok 18:21:46 did tobtoht actually say this somewhere? he gave that whole engineering explanation of why equix over randomx that made sense 18:22:21 I thought Equix was someone else , but I could be wrong 18:22:24 I think I heard this argument many years ago already 18:22:40 https://github.com/tevador/equix/blob/master/devlog.md 18:22:56 After GUI, I'm going to work on the Rust carrot library, and then probably HW devices and multisig 18:22:57 In tevador we trust 18:23:39 oh lol I actually just mixed up tobtoht and tevador (sorry tobtoht and tevador), my bad 18:24:01 I blame monday 18:24:02 Who seems to be missing, unfortunately. I saw somewhere with a German translation for Polyseed which is now probably in limbo 18:24:14 *somebody 18:24:28 I think tevador is koe's alt 18:25:02 this was supposed to be a joke but I don't manage to find good way to put it 18:25:03 forget it 18:25:32 That'd be crazy lore 18:26:02 That Rust Carrot library, that's something that will be first used for Serai, I guess? 18:26:23 https://matrix.to/#/!mehPttlWNbDtNeDbvu:monero.social/$skmafkmWjQq9ow9HVN9HrTdH6hLROs99uK9OKbJzpE8?via=matrix.org&via=monero.social&via=hackliberty.org 18:26:36 I hope that link works. Not a completely clear statement 18:26:59 it works 18:27:05 and Cuprate I think 18:27:16 Ah, yes of course 18:27:29 tobtoht said: 18:27:30 > All it took to bypass Monero detections for most AV vendors was to change a few strings. We're down to 2 detections now on Windows binaries, from completely irrelevant AV vendors. 18:27:32 > Well, that, and strip out RandomX. 18:27:55 If Cuprate is node-only code, then it doesn't need almost any carrot code whatsoever 18:27:57 "We" I think means Feather wallet. 18:28:36 alright thx for clarifying 18:28:40 I dimly remember similar statements, like already mentioned years ago already 18:28:57 For consensus, Cuprate needs to define the new output type variant, and that's about it. It doesn't need to know anything about it besides how to serialize/deserialize 18:29:22 Those false positive flaggings of our software on Windows are a big PITA 18:30:52 But probably not important enough to go down some sub-optimal route for that new PoW use 18:31:02 Sadly 18:32:01 Alright, beside these reports, do we have anything more to discuss today? 18:32:05 I remember when Avast integrated a crypto miner into its free software. This is probably the incarnation of hypocrisy within antivirus 18:32:31 Right, *that* crazy story 18:32:34 Isn't EquiX supposed to be must faster to verify than RandomX? 18:32:47 much* 18:32:49 Yes 18:34:37 It's like 50µs on a Ryzen 1700 18:35:18 if we're allowing 8 input txs without PoW, that gives an allowed window of (rough estimate) 200ms for PoW verification, whereas RandomX with light memory verification "takes around 15 ms" (from that linked rationale above) 18:36:35 I don't understand. How do we "allow" something? Don't we want everything as fast as possible? 18:37:07 FCMP++ verification of a 8-input tx will inherently take about 200ms is what jberman is saying 18:37:12 ^ 18:37:35 Yes, and thus you want to add to add as few cycles as possible if you go to more inputs yet, no? 18:37:38 So RandomX time-to-hash is almost always going to be faster than FCMP++ verification 18:38:14 we need to create miner templates 18:38:16 ideally optimizations will bring that FCMP++ verification time down a significant amount, but regardless, I don't expect we'll get 8-input FCMP++ txs verifying in less than 15 ms 18:38:41 True... I forgot about that 18:38:46 don't know how much carrot that will be, probably a nibble 18:39:10 Maybe I confuse which party is doing which work right now 18:39:15 * m-relay whispers variable time performance gains are worth the maintenance burden 18:41:39 The way that I envision it is that PoW is required on the p2p layer for someone to *send* a mempool transaction. So whoever originates the transaction must create PoW. If you are relaying the transaction, you can also relay the PoW proof without doing more PoW. Now, either A) the daemon which receives the transaction over RPC can do the PoW for that transaction or B) the wallet wh ich signs the transaction can do the PoW 18:41:54 ok for rbrunner7 : backing up, the core issue for large input FCMP++ txs is that it takes a long time for a node to verify a single tx (e.g. a 100+ input tx could take seconds to verify). and so we brought up PoW-enabled relay as a "solution" to this in that if you want to send a tx to a node and get that node to verify it so it can add it to its pool, then you have to attach a Po W to that tx demonstrating ~seconds of CPU-time, to make it more costly for a malicious actor to get a node to do verification of bad txs 18:43:22 in the meeting we discussed only requiring PoW verification on FCMP++ txs with more than 8 inputs, since it may be relatively acceptable for nodes to take up to 200ms to verify 8-input FCMP++ txs 18:43:54 This will be most of the stuff in the `enote_utils.h` file in the `carrot_core` module in the C++ repo. This doesn't cover scanning, address generation, or advanced transaction creation 18:45:03 now since we're saying it's acceptable for nodes to take up to 200ms to verify an 8-input FCMP++ tx, then we have a 200ms acceptable verification window for the PoW on relayed FCMP++ txs, and so we don't necessarily have to use equix for the reasons tevador chose it for tor 18:45:17 and can reasonably stick with randomx 18:45:25 So the argument goes that if you already spend more than 200 ms to just verify the transaction, with no way around that of course, 15 ms or so to verify whether the PoW is correct does not matter too much, in comparison? Not much won to bring that down to, say, 1 ms, with EquiX? 18:45:42 right 18:45:47 I see 18:45:56 That makes sense 18:46:40 Main appeal of EquiX over RandomX was originally its memory constraints. 1.8MB vs 256MB. 18:47:06 Ok, funny how such a quite new element pop ups so late on the way to FCMP++ :) 18:47:24 Quite a surprise, at least how I see it 18:47:29 Our PoW discussed here wouldn't be applicable to txs already in mined blocks, just relaying mempool txs, since txs in blocks obviously already PoW done for them 18:48:24 IMO this has no effect for our use case since nodes already have their RandomX cache loaded up and ready to go 18:49:47 oh maybe i missed something I assumed wallets were doing the PoW. It's confirmed that broadcasting nodes are doing it? 18:50:16 It's definitely not totally decided, but the 8/8 limit came up as a big point of contention, so if it's feasible to use PoW to get rid of the 8/8 limit, I think it's worth looking into 18:50:39 Looks like a "political" decision, not only a technical one? (Who does the PoW) 18:51:12 Absolutely, I don't think anybody is really happy with that 8/8 limit 18:51:46 Okay yes if the wallets do it, then *maybe* it's a constraining factor. That is, if scanning memory usage already is lower memory than RandomX lite mode, which jberman argues it's not 18:53:19 personally I think it would be simplest to have wallets do it 18:54:10 btw I also brought up a potential fingerprinting issue and then didn't expand on the point, but here it is: if some wallets don't implement >8 input txs because of the new PoW rule, then wallets that send >8 input txs stick out 18:54:12 Oh yes, maybe having the daemon doing it may reduce the number of people offering public nodes considerably 18:55:03 as in, you receive a >8 input FCMP++ tx, you know that it must have come from a wallet implementing the feature, and not another wallet 18:55:42 I don't think doing PoW for dozens of connected wallets sounds attractive :) 18:56:20 That would be the exact other way round than that micropayment scheme, how was it called already? 18:56:32 Pay for RPC or something 18:58:33 Alright, we are nearing the full hour. Let me close the meeting proper, while discussions can go on of course. Thanks for attending everybody, read you again next week! 19:01:06 Probably, although I would like to see the option for daemons to do it after receiving a raw tx, so that wallet vendors at least have the option of not including the RandomX dependency 19:01:06 thanks, very interesting 19:01:28 Thanks rbrunner7 and everyone else! 19:02:56 ya I guess the latter would need to be a requirement for windows wallets