15:08:50 MRL meeting in this room in two hours. 17:01:07 Meeting time! https://github.com/monero-project/meta/issues/1200 17:01:12 1) Greetings 17:01:19 Hi 17:01:29 Hello 17:01:32 Hi 17:01:58 hello 17:02:12 seawas 17:03:11 *waves* 17:03:28 2) Updates. When is everyone working on? 17:04:47 Better subnet de-duplication when connecting to peers, to connect to less "spy nodes". Made good progress in the last few days. 17:04:51 me: Working with rbrunner7 on subnet deduplication for peer selection and setting up tests. I took over as maintainer for the `IP` package on CRAN: https://cran.r-project.org/package=IP . My `xmrpeers` package depends on it: https://github.com/rucknium/xmrpeers , but it was removed from CRAN in January due to issues that I've now fixed (with some help from moneromooo ). Working o n a custom loss function for neural net classification of real spends when multiple decoy selection algorithms are used in the wild. 17:06:00 me: moving forward outstanding PR's, pushed a draft PR demonstrating memory safe FFI usage (https://github.com/seraphis-migration/monero/pull/39), currently 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 input txs >8 last MRL meeting, so that nodes don't expose a vector to hog CP 17:06:02 U verifying invalid FCMP++'s) 17:06:08 Me: finished lws-frontend subaddress support and restore from height. Currently working on tx construction for same frontend and x25519 updates for arm64 17:07:43 jeffro256: ping in case you want to join the meeting. 17:07:48 3) FCMP stressnet preparation. 17:08:12 me: successfully tested Carrot+FCMP transaction construction and scanning in the GUI wallet. Working on improving code quality wrt documentation and error handling 17:08:26 It has been brought to my attention that a few PRs intended to fix issues found on the last stressnet have not yet been merged into the main Monero repo. 17:08:55 ✅️ mean merged. ❌️ means not merged 17:09:10 ✅️ [Blockchain: fix temp fails causing alt blocks to be permanently invalid](https://github.com/monero-project/monero/pull/9395) 17:09:10 ❌️ [Daemons processing big blocks may bump against serializer sanity checks and fail to sync](https://github.com/monero-project/monero/issues/9388) 17:09:12 ✅️ [tx\_pool: update internal data structure to boost::bimap.](https://github.com/monero-project/monero/pull/9376) 17:09:14 ✅️ [cryptonote\_core: only verify txpool when the hardfork value has changed.](https://github.com/monero-project/monero/pull/9404) 17:09:16 ❌️ [src: dynamic span, to calculate span limit dynamically](https://github.com/monero-project/monero/pull/9495) 17:09:18 ❌️ [src: dynamic block sync size](https://github.com/monero-project/monero/pull/9494) 17:10:08 So, will the FCMP stressnet have these PRs, or not? If yes, then it would be assumed that these are necessary PRs to deploy before or at the time of the FCMP hard fork. 17:11:35 The three that have not been merged are important to be able to not have a netsplit when blocks are large, IIRC 17:12:02 The last 2 *should* be less controversial IMO, and could probably be merged before then. But the "Daemons processing big blocks may bump against serializer sanity checks and fail to sync" is a little tricky in that directly increasing serialization limits directly increases area of attack for DoS 17:14:50 Looks like #9388 fell through the cracks, as nobody looked at the possible dangers of higher limits in detail ... 17:15:29 > The three that have not been merged are important to be able to not have a netsplit when blocks are large, IIRC 17:15:30 If anything it's the opposite for the 9388. Everyone having the same low limits means no netsplit, the block is just rejected outright. If people had *different* limits, that's what would actually cause a netsplit 17:16:04 would need to review these all in more depth 17:16:25 I recall differently. 17:16:37 Aren't connections drop after receiving big blocks with the current limits in place? If I remember correctly it's also a security issue 17:16:40 >Block sizes at this height were about 1.5MB. Then it banned some peers. The bans expired after 2 minutes because we set a new ban duration in the code. 17:16:42 Or maybe possible netsplit in both scenarios. 17:17:27 Problem is, the blocks were perfectly legit, just chock full with valid transactions 17:17:34 IIRC, what happened early in the stressnet was that miners started mining just on top of their own blocks because they started banning other miners with big blocks. 17:18:24 True, might just be different types of net splits, I need to look at it again. I can imagine where the serialization limit is enforced when the packet is formatted a certain way, but if the packet changes, but contains the same block, it's accepted 17:18:32 here is a PR increasing the limits: https://github.com/monero-project/monero/pull/9433 17:18:38 Ah, makes sense 17:19:09 and another one https://github.com/spackle-xmr/monero/pull/12/files 17:19:12 if its a fluffy block the number of txs sent depend on the number of txs already known 17:19:44 Excellent point 17:20:22 Ah, yes, I now remember #9433. So we just did not achieve consensus there, and merged the bloody thing :) 17:20:36 So it's deeper than just simply increasing limits, since the method by which it's limited inherently causes net splits 17:22:34 IIRC, things got bad when a node fell behind by more than one block. Then, probably, the node needed to do a normal full-block sync instead of a fluffy block sync. 17:22:52 Not sure whether the net will split, or whether the daemons with too-low limits for all the huge blocks simply stop working 17:22:55 And then got banned 17:23:22 yeah I think to properly solve this we need a better epee bin impl 17:24:32 Perhaps we could name this PR "Replace serialization functions" 17:24:56 Anyway, as I said, it's also a security problem, somebody could now spam the network so hard as to create mayhem because of those limits 17:25:30 are the epee limits to prevent a memory leak? what if all kind of throttling / banning was removed and rethought from the ground up? it seems so entangled everywhere. be it rpc code, serialization, p2p 17:25:38 Good luck with replacing those functions :) 17:26:01 No, I think they are there to prevent out-of-memory attacks with specially crafted packets 17:26:19 There are some details in the PR discussion 17:26:29 IIRC, some of the limits were put in place to handle deserialization explosion during the December 2020 network attack. 17:26:32 at #9433 17:26:49 Yeah what if we used a streaming serialization model instead of DOM? And maybe put it in a cool number PR number like 8867 17:27:05 AFAIK, a good solution would be to prevent deserialization explosion in the first place. 17:27:28 rbrunner: how come something like protobuf never runs into issues like this. what is wrong with epee? :D 17:27:34 cuprate has no limits like this 😏 17:27:56 Maybe nobody feels like attacking protobuf? 17:28:54 And it's not possible to exhaust the memory with Cuprate? 17:29:12 If we just take out those limits, we don't have any either :) 17:30:10 Monero Unlimited 17:30:42 We don't use a DOM, I don't want to say impossible but I don't know a way. 17:33:03 or epee bin impl is also zero copy for the most part, using references into the original bytes. 17:33:05 A couple things: most protobuf libraries are SAX instead of DOM meaning that they stream the data directly into the deserialized types and constrain that data to the type's requirements, which greatly reduces the funkiness of the packet you can send to a Protobuf deserializer. This is effectively what PR #8867 aims to do. Second, the epee binary format is a lot like JSON: it is se lf-describing and can have fields in any order with unlimited nesting. So even when you have a SAX-like API to deserialize epee binary format, you have to contend with jumping around in different places when deserialiing member fields or implement something like lookup tables. You also generally have to ignore valid key-values in objects when you don't know the name of the field, which means an attack can stuff a weird payload in there 17:33:10 Protobuf doesn't use a dom, so it partially prevents the issue, although it should still be possible to explode memory with a vector of strings 17:35:15 Protobufs also typically have smaller limits on total payload size, whereas we have a big buffer for block fetching 17:36:01 Like if we could limit the payload to 1mb, we probably wouldn't need to place additional limita 17:36:07 *limits 17:38:00 It might cause a netsplit, but could a good long term option, when multiple blocks are fetched, be to stream the blocks one at a time over a keepalive connection, each limited to say, 1 MB? And the receiver would only deserialize the next packet after completely processing the former ? 17:39:09 (sounds a bit like grpc :D ) 17:41:30 Some ideas have been proposed and discussed. I doubt this will be settled today. Next meeting, the PRs to be included in the alpha stressnet could be decided. 17:41:30 Any more issues for stressnet prep that should be discussed today? 17:43:35 What happens when the block size is over 1MB? 17:43:57 connection dropped 17:44:18 The #monero-stressnet:monero.social room still exists. Some coordination can be done there. It is bridged to ##monero-stressnet on Libera IRC, I think. 17:45:07 So are we capping the block size? 17:45:42 Indirectly, yes 17:46:04 There is no consensus for this 17:46:19 And blow holes into the network as a second effect 17:47:12 Period This has to go. 17:48:45 The other option would be to split a large block over multiple discrete packets, but this has another DoS effect: the node sits there waiting around for the 2nd packet, wasting RAM until the connection drop 17:49:31 akshually we could add some PoW for the block fragmentation 17:49:37 yes this is a mad idea 17:49:41 but i don't have a better one 17:49:44 I have thought for a while that the P2P messages need to be rethought, we already currently have a cap on block size. 17:51:21 everything needs to be able to broken down to sending 1 tx at a time as that is the thing that actually has a size limit 17:51:36 The stressnet continues to provide valuable feedback, even almost one year later. 17:52:07 That is a sensible idea 17:52:26 things _can_ be batched but if they are too large they should be broken down, this also needs to happen on the response side as the requester often doesn't know the size of things they ask for 17:53:40 i.e. someone asks for a block but that block is 500 MB, we need to send multiple messages to actually send the block 17:53:42 ... But still multiple packet connections are the norm on the Internet 17:55:21 also things like the tx-pool request have to be a DOS if the tx-pool is huge, it can't be good to load all the txs into memory. 17:56:08 Uh, the tx pool is a whole other can of worms ... 17:56:12 And when syncing a single block header to check PoW, you only need <96 bytes. The transaction list inside a block is actually a merkle tree, so you don't even need to send the entire transaction list at once 17:57:23 In fact more often than not the transactions may already be at the receiving end 17:58:21 yeah let alone the fact now we send every tx, in full,when syncing not just the hashes. 17:59:30 before we know the chain is even valid 17:59:55 Exactly 18:00:31 rename FCMP++ to Monero 2 and change everything? 18:00:44 I've the impression that in many aspects, the original monero code has been done the "naive way" 18:01:22 or maybe they were ultra optimistic 18:01:42 4) FCMP++ transaction weight formula. And PoW for high-input txs. https://github.com/seraphis-migration/monero/pull/26 18:02:10 I think they just hacked something together with 2013 cryptocurrency knowledge until it started working 18:02:15 Which, like, fair 18:02:49 they had to get the scam out quick 18:03:21 Bytecoin 18:03:54 So, it is thought that PoW for high-input txs is a good compromise that prevents the DoS attack vector of verification of invalid inputs proofs and allows high-input txs for good user/service experience. 18:04:08 So maybe everyone can be happy 18:04:26 Yes, somewhat surprisingly 18:04:33 At the cost of more protocol complexity 18:05:54 The RandomX difficulty threshold and the max allowable number of inputs is still to be decided, AFAIK. But maybe those exact values can wait until there are benchmarks on the optimized verification code. 18:07:13 I don't have a case against this POW thing over 8 inputs.. This being said large transactions will have to pay a higher minimum fee so that they don't depend on smaller transactions to do the scaling for them 18:07:29 As is the case bow 18:07:44 Now 18:10:05 Right now scaling is based upon 3000 bytes. After FCMP++ this will rise to 10000 bytes. Anything larger will need to pay a higher fee so that it can scale on its own 18:13:10 Essentially every transaction needs to pay a large enough fee so that it can pay the penalty at the start of the penalty 18:16:22 Is that at the minimum fee level (first tier), or a higher fee level? 18:18:16 The minimum fee is currently based upon 3000 bytes and will rise to 10000 bytes. So these large transactions will have to pay a higher minimum fee depending on their size 18:20:06 5) Web-of-Trust for node peer selection. 18:20:30 flip flop gave some thoughts about this at last meeting 18:20:49 Why isn't the minimum fee set as a factor of the weight of that transaction ? 18:20:54 Some thoughts: 18:20:56 a) We operate in an environment where a global actor may rent CPUs. I think in the long run relying on hashrate alone for consensus will be difficult. If solo-mining becomes more profitable that might raise the bar for an adversary. 18:20:58 b) WoT: A naive rating system as in pgp key signing may backfire. I thought about the concept of "anchor nodes". Would it be feasabile to zk-proof good behaviour such as availability, contribution to consensus, or even taking on a watchdog role? The idea is that an adversary might have trouble faking such a track record. 18:21:00 Just brainstorming. 18:21:27 https://libera.monerologs.net/monero-research-lab/20250430#c522508-c522510 18:21:31 This is the change that I will be proposing 18:22:52 Won't the introduction of FMCP++ take away a lot of the possible / plausible reasons of attacking / subverting the network, like the "spy nodes" now? 18:23:35 If I understand correctly, BTC has a ban score that raises if a node seems to be misbehaving. When ban score 100 (I think) is exceeded, the peer is banned. I think Monero does not have a ban score. An offense is either bannable immediately or not bannable. 18:23:42 Ah, no, trying to defeat Dandelion++ stays of course 18:23:51 Ban score is not exactly web of trust, but similar 18:24:22 The main attack it takes away is Flood XMR / black marble 18:24:39 Maybe IP-based de-anonymization is all that an adversary would have left, so more effort would go into it. 18:26:07 AFAIK, Nym has done interesting things in this area, since they have some mechanism to check if a mixnet node is actually providing the bandwidth it says it does. This check is necessary for their economic rewards to mixnet nodes. 18:26:09 True but Monero privacy uses the whole is greater than the sum of its parts 18:26:49 no... worst case is Monero becomes sucessful ad adopted. Then the attack vector is 50% hashrate. 18:27:02 So completely breaking tracing will have an impact on IP address based attacks 18:28:27 And Tor does something like Nym to measure node bandwidth, but simpler I think. Maybe their method isn't trustless. 18:29:32 re `a)`: not relying on heaviest-aggregate-PoW as the fork choice rule on a PoW chain seems to be contradictory. I've been thinking about a short-term PoS overlay for reducing the n-block lock depth, but the eventual chain should follow heaviest-aggregate-PoW. 18:29:55 I don't think p2p web-of-trust could prevent a 51% attack. 18:31:04 yeah, WoT is ot the way to go. I thought about the concept of "anchor nodes". 18:31:39 *not 18:32:43 We have to be very careful reaching conclusions here regarding POW. Accounting for the value and cost of the heat produced by POW and environmental considerations strongly favor decentralization 18:34:04 @articmine:monero.social I am with you. Is solo mining profitable right now ? 18:34:26 It depends on the temperature outside 18:35:10 I want some chinese miners, also. 18:36:05 By a standard economic argument, mining XMR is unlikely to be very profitable as long as it is only feasibly mined by CPUs. CPU mining allows free entry, which drive economic profits to zero. 18:36:11 On average 18:36:35 I January are you in Alice Springs, AU or Winnipeg, CA? 18:36:39 Solo mining vs pool mining are only different in the frequency of payouts, and therefore the risk. 18:37:19 "anchor nodes" turn economically incentivized, permissionless consensus into social consensus. 18:37:44 Or is the outside temperature 40 C or - 40 C? 18:39:45 yes, thats my argument: adding a trust score to augment PoW -- in case of a 51% attack. 18:41:11 Having a rolling checkpoint would be a simpler 51% attack defense. It would require nodes to stay online to avoid being confused by which chain is the "correct" one. 18:41:19 yes, thats my argument: adding a trust score to augment PoW -- in case of a 51% attack. It happened to Firo. They had to augment PoW with "masternodes" 18:42:26 how do you do that "augmentation"? the idea of PoW consensus is that you rarely if ever have to rely on social consensus, and social coordination happens outside the protocol. if you include it in the protocol, the anchors can 51% attack consensus for cheaper than adversarial hash power could. 18:42:32 yes, i thought about "light nodes" to do that 18:43:45 catch 2:2. The question is open. 18:44:20 this would add a novel liveness assumption to the consensus model, and it's exactly something that Nakamoto consensus is designed to partially remedy. 18:44:40 chaser: Right. 18:45:10 Still Monero defeated a 51% attack in 2018 with the ASIC dock. 18:45:19 Food for thought 18:45:32 Fork 18:46:09 This is in the bitcoin white paper abstract: 18:46:10 > Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. 18:46:42 I just want to raise awareness that the $ cost is about 500k per month to rent 5G hashes 18:46:49 So the block checkpoint defense is contrary to the bitcoin white paper protocol. 18:46:55 Arguably 18:48:32 I'd like to see more rewards for miners. 18:48:33 Let's "officially" end the meeting here since we are 50 minutes past the hour, but feel free to continue discussing. Thanks everyone. 18:48:44 yes. notably, Nakamoto consensus can't answer what to do if you come online and see two equally heavy chains, or solve the problem of not hearing about a heavier chain, but it reduces the probability of those events considerably. 19:07:19 that you can achieve only through a higher inflation rate *while* the fiat price of XMR stays the same, or an absurdly high minimum fee requirement in the consensus. both are unlikely, especially the former. there is a very strong consensus on Monero's monetary policy, and the demand for XMR wouldn't increase in proportion to the added supply. 19:11:05 You tough on an interesting point here... but I am so innocent, miners could get donations, right ? 19:11:38 if the $/second PoW "security budget" for Monero is too low compared to a level you'd prefer, I hear you. the way to improve on that is to make XMR more valuable through research, development, adoption, education, community building, UX improvements, and so on. 19:15:07 Well, it could be a self-adjusting system, where the price of XMR rises with adoption, which in turn makes 51% attacks way harder to do, because hashrate increases. Thats an optimistic outlook. I like that. 19:21:25 they already can, but you can't make sure they'll use those funds for hashing. that would require some kind of on-chain donation box that would drip its contents over time to the miners. 19:31:19 was there an actual 51% attack in 2018? 21:47:33 Going to share some preliminary thoughts on using groups of max 8-input membership proofs in a single tx for txs with more than 8 inputs, versus just using a single n-input membership proof 21:47:43 Pinging kayabanerve (especially in case there are inaccuracies in here) 21:48:10 Pros: 21:48:10 1) Constructing proofs for large-input txs takes forever (minute+ for 32-input+, and looks like potentially double digit minutes for >100-input proofs) 21:48:12 On those grounds alone it probably makes sense for each tx to have groups of max 8-input proofs. Maybe @kayabaNerve has thoughts on potential optimizing for that scenario? 21:48:14 2) Looking at preliminary verification times, max 8-input proofs make a lot of sense too, even ignoring the benefits of batched verification for multiple 8-input proofs being superior to the aggregate (mentioned by @kayabaNerve) 21:48:16 E.g. a 64-input proof is taking 2.4s to verify, compared to 1.4s for 8, 8-input proofs individually verified (179ms each) 21:48:18 3) There is also the benefit @boog900 highlighted last MRL meeting: if an attacker wants to hog a node's CPU with invalid txs, for maximum damage, they could include all valid proofs except the last, which means they have to do additional work to construct valid individual proofs (have all valid proofs except the last to hog node resources). Constructing valid proofs is not an ins 21:48:20 iginifcant amount of computational work 21:48:22 4) More conducive to multithreaded verification of single txs 21:48:24 Cons: 21:48:26 Proof size. A 128-input membership proof is expected to be 79232 bytes, versus 16, 8-input proofs is 153600 bytes 21:48:28 The former is pretty comparable to CLSAG. So we're talking about large input txs nearly doubling byte size 21:59:20 Another benefit (or con?) that I haven't seen mentioned: it opens the door for collaborative multi-sender transaction building without the need for MPC as long as the inputs are grouped in different FCMPs. It wouldn't be very dependable since one of the parties need 8 contiguously ordered key images that don't overlap with the other party, so .... 22:02:29 That is, without revealing the true spent output to the other party. If you don't care about that, you can always have the other party prove the FCMP for all inputs in the group. 22:02:58 Although, if we write the code to support multiple FCMPs per transaction, we could likely trivially configure it so that the transaction creator can provide an arbitrary grouping of FCMPs (as long as they're of size <= 8). For example, if only a 2-in, the tx could provide 2 1-input FCMPs. That's actually sort of usable for collaborative transaction building 22:03:18 There's the uniformity issue of allowing arbitrary groupings, though 22:03:24 IDK just food for thought 22:06:39 > There is also the benefit @boog900 highlighted last MRL meeting: if an attacker wants to hog a node's CPU with invalid txs, for maximum damage, they could include all valid proofs except the last, which means they have to do additional work to construct valid individual proofs (have all valid proofs except the last to hog node resources). Constructing valid proofs is not an insi ginifcant amount of computational work 22:06:42 On this, we can always shuffle the order in which we verify FCMPs so it's not predictable to the sender. Then in the best case (for us) we fail after the first FCMP. The attacker can only expect 1/2 of the FCMPs to verify on average 22:26:52 Yep^ that would make it even harder on attackers with the max 8-input proof construction 22:28:13 main point being the max 8-input groups obligates the attacker to do more computational work on their end to attack a node 22:32:50