16:53:58 Meeting in a bit more than 1 hour 18:00:02 Meeting time. Hello! https://github.com/monero-project/meta/issues/1202 18:00:24 hello 18:00:46 *waves* 18:00:50 hello 18:01:55 So, what is there to report from last week? 18:01:58 I finished coding the improved peer selection code. Rucknium is currently testing it. 18:03:07 working on replacing wallet2 with Wallet API in simplewallet 18:03:24 Oh, good. That will become a nice milestone. 18:04:20 I noticed I missed some functions for the API that are in wallet.h but not in wallet.cpp for #9664 18:05:10 Nothing beats actual use of an API to check it :) 18:05:17 me: mostly worked on FCMP++ input limit-related work last week. I bumped input limits to 128, tested it out, and shared in MRL some preliminary thoughts on using groups of max 8-input proofs in single FCMP++ txs rather than individually large input proofs 18:05:57 Howdy sorry I'm late 18:06:24 Thanks for taking the initiative there ! 18:08:07 By the way, I tried to find some clear info about the size in bytes of FCMP++ transactions, depending on the number of inputs and outputs. I am pretty sure that exists already, and that I saw that once somewhere, but couldn't find it. Does somebody have a link? 18:08:42 jeffro256: Yeah, I surpised myself to find such a nice piece of Monero coding work within my reach. 18:10:27 I can post a template for that today assuming default carrot tx extra size 18:10:40 *table not template 18:11:01 It might get more interesting still because somebody might have found yet more "spy nodes" ... 18:11:12 (talk over in /dev) 18:11:37 here's a table that shows membership proof byte size by n inputs and n layers: https://github.com/j-berman/monero/blob/84daa22a878544fe2e7536f4b047e872ff8c21cb/src/fcmp_pp/proof_len.h#L43-L173 18:11:38 doesn't include other tx components 18:12:45 the tree currently would have 6 layers, and bumps to 7 layers around 300mn outputs in the chain total (we're currently at ~150mn, probably a bit higher now) 18:13:22 SA/L proofs are an additional 384 bytes per input 18:13:27 jberman: At first sight, that table looks pretty strange What is such a table needed for? 18:15:26 We determine how large the FCMP++ proof should be from a tx's n inputs and n layers in the tree when de-serializing the tx. That calculation is slow/expensive. To avoid making de-serialization slow, we include a table with all pre-calculated values for fast lookups 18:15:59 note if we were to stick with max 8-input proofs in single FCMP++ txs, that table would be way way smaller (only the first 8 rows) 18:16:09 Ah, ok. I just hope that won't be brittle somehow. 18:17:49 fwiw I also included a unit test that re-does the calculation for every table value and checks against the table 18:18:04 Although that doesn't address all brittle-prone concerns 18:18:07 Oh, that's nice 18:18:11 Good idea 18:19:18 And now to my weekly curiousity question: Anything new regarding the contest? How many entries does the leaderboard have already :) 18:20:07 No valid submissions yet :( We got a couple that both look like AI unfortunately, neither work (one doesn't compile the other doesn't pass tests) 18:20:12 I've seen several private repo invite links but honestly haven't looked at any submissions 18:20:48 So at least there is some movement, somewhere 18:21:36 xmrack is reaching out to zprize contestants from here https://www.zprize.io/blog/announcing-the-2023-zprize-winners 18:22:04 it should help that the fiat value of prizes has gone up too 18:22:42 Certainly. XMR in USD has a remarkable run lately. One can only wonder. 18:23:39 Alright. Anything more to discuss today beyond the reports? 18:24:32 *Luke if you see this message please submit the best code imaginable anonymously pretty please 🙏* 18:25:23 Doesn't look like it. I think we can close the meeting already. Thanks everybody for attending, read you again next week! 18:25:51 thanks everyone 18:27:32 I noticed I missed some functions for the API that are in wallet.h but not in wallet.cpp for #9464 19:19:08 rbrunner7: 19:19:26 https://matrix.monero.social/_matrix/media/v1/download/monero.social/DxYhgCCxiouMqobACZzVyYbp 19:20:10 Some tables for Carrot/FCMP++ tx raw byte size 19:21:07 "varint fields minimized" means that where there is a variable-length fields, it takes on its minimum-length value. Same for "varint fields maximized" but opposite 19:24:41 Thanks, jeffro256 , very interesting! 19:29:40 The minimum size is a bit of a shocker at first, frankly. But thankfully it does not get worse too fast with higher numbers of inputs and outputs. Sizes go back more or less to pre-bulletproof times. 19:41:48 Looks like size growing by ~50% everytime you double inputs... sooo.. more inputs = less bloat 🙃? 19:42:33 re jeffro256: 's chart 19:44:25 Like, the chart makes 2x4 input tx's look terrible compared to 1x8 19:44:55 (20kb vs 15) 19:55:20 This is true, the FCMPs scale decently in terms of size with increasing number of inputs. The main issue is turnaround CPU time for verification 19:56:49 how does the cpu time scale though? 4x8 vs 2x16 vs 1x32 19:57:15 If its linear, i'm not sure i'm understanding the/any reason for limiting 20:00:07 jeffros ods chart https://node2.monerodevs.org:9000/uploads/2ebb6108e3c87161/carrot_fcmp_tx_size.ods 20:00:25 Because a high-input FCMP will take a concretely high amount of CPU time to verify. If a peer spams fake txs, this can cause a DoS attack 20:03:04 ofrnxmr: https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$NtOhg5VRnVj9k8m0DR-46wBpM1uF2KJMiHOIG9o4qo4?via=matrix.org&via=monero.social&via=cypherstack.com 20:04:22 Block peer if they send more than a few fake txs 20:05:41 You can't block someone without first attempting to verify the transaction, which is the part that takes time 20:05:50 Why would you need more ips? 20:06:02 And you can already hammer a node with simple rpc calls 20:06:11 Dont have to send anything to the node 20:06:47 So it can dos with 2-3txs ? 20:07:33 Theres nothing stopping me from submitting 1000s of tx immediately right now 20:07:46 From 1 ip 20:08:10 Presumably you get blocked after a failed verification time. So if some operation takes 200ms and then you can ban, versus 20ms and then you can ban, to get the target to waste 200ms of CPU time, you need 10x more IPs with the 20ms operation 20:08:10 public rpc nodes have many vulnerabilities as we know 20:08:44 I'm taking about the p2p protocol 20:08:48 How are you going to block me when i submit the tx before you verify any? 20:08:55 200ms to verify tx with how many inputs ? 20:09:03 Hm. 20:09:07 8 20:09:32 With a sufficiently high input count and depending on the target CPU capabilities and what you're trying to achieve with an attack 20:09:36 And how much time for 16/32 inputs ? 20:09:54 Linear, sounds like 20:10:03 An 80inout = 2s 20:10:11 (seems what jberman was saying) 20:10:30 Submitting the txs don't really take any CPU time besides what is need to allocate buffers, etc. FCMP verification *does* take a non-trivial amount of CPU time 20:10:37 An 80input = 2s 20:10:41 I don't have to verify anything you send me if I don't want to 20:11:35 Ok, so if i consolidate 100 inputs, youll block my node? 20:11:55 I dont see how this prevents anything 20:12:02 Don’t need 80 inputs, 16 input 400ms 32 input 800ms would be bearable 20:12:04 This is all without optimised code right ? 20:12:36 If i'm relaying 80 inputs, i'm doing it regardless of whether its 200ms * 8 or 2000ms * 1 20:12:54 Idk if I have exact numbers for this on hand for a realistic number of FCMP tree layers atm, sorry 20:12:57 To verify 20:13:22 Let’s get numbers before we cap 8 input 20:13:38 or, i guess it depends if its a malicious tx that fails to verifh 20:13:54 If we limit the tx input count by consensus rule, I won't ever call `verify()` on a tx with 100 inputs and skip the DoS 20:14:17 If >350ms on my machine, I know that 20:14:31 Which is pretty significant 20:15:14 That’s for 16 inputs ? 20:15:20 No way to do some sort of light verification before spending time on the full tx? 20:15:45 **jeffro's AMA** 20:15:52 I'll just ban you by reason of sending me a 100-in tx to deserialize when you should know it isn't allowed 20:16:09 https://libera.monerologs.net/monero-research-lab/20250507#c524274 20:16:13 This is basically the PoW idea proposed in the MRL meetings 20:17:14 Could be >1000x times faster to verify RandomX PoW than FCMP proofs for high-input txs 20:18:22 https://libera.monerologs.net/monero-research-lab/20250507#c524279 20:20:53 I can also agree that we don't _need_ huge input sizes like 146 (which is currently obnoxiously 1/3rd of the block size) 20:20:54 if we take the current consensus limit on tx size that would be about 120 inputs max, which seems fine 🤷 20:21:34 But that 8 harms ux and bloats nodes 20:21:43 UX? 20:22:15 https://github.com/monero-project/monero-gui/issues/4443 20:22:56 it's batches of 8 inputs per FCMP, the proposal was for a single tx to have multiple FCMPs 20:23:36 I see the bloat argument - its a trade off 20:23:51 Yes, this is also the other dimension that I hadn't brought up yet that I should have 20:23:52 what do you value more/where are the limits 20:25:43 If we keep using the checkpoint system in the future, the asymptotic cost of CPU verification time of the chain is O(1). But the bytesize bloat stays forever 20:26:45 but if the P2P network can't handle txs that take 2 seconds to verify, we can't get the savings without putting nodes at risk. 20:26:52 spam attacks can, imo, cripple the network (with valid tx) 20:30:01 I agree, it will be interesting to see how much that is due to inefficient in the implementation rather than the tx protocol though 20:30:32 I would lean to it more being a monerod issue rather than a Monero issue 20:30:54 are there Monero issues that aren't monerod issues ? 20:31:50 every Monero issue is a monerod issue not every monerod issue is a Monero issue 🧠 20:32:00 P2pool consolidations 20:32:53 don't hesitate to repeat it for the next century or so, maybe sech1 will consider it 20:33:02 Probably an elephant in the room 20:33:56 extremely small elephant imo 20:34:20 inb4 400 page essay about why p2pool consolidation is le bad 20:34:25 Small elephant with big bloat 20:34:26 Non-p2pool consolidations are one thing, but most "normal" people end up with thousands of inputs of less than 0.0005 xmr 20:34:28 its average 😠 20:34:48 Maybe an order of magnitude off,its been a whole 20:35:16 Want to reduce bloat lads? JUST ZIP THE DATABASE 20:35:35 Ozempic 20:36:42 anyway im very happy to have led this serious channel into a useless discussion 20:37:05 thanks syn 20:38:20 the 16*8 isnt that much larger than 146 current 20:38:36 About 171kb for 146 inouts using the 16*8 math 20:38:53 # "x*y math" 20:38:59 About 70% larger🥲 20:40:43 The issue of peers spamming bad tx via p2p - what stops my node from relaying 1000 tx to your node? You can block me after the first bad one, but you're still stuck with the 999 other tx 20:41:53 Its not like the node only allows 1tx per node, and i dont think nodes track where the txs came from (?) 20:42:33 the txs are added one by one, if one is invalid the others are dropped 20:42:54 we verify 1 and don't verify the other 999 20:43:27 inb4 but muh bad tx can be put at the end 20:43:29 Track which tx was sent by which peer, discard tx pending verification which was going to be blocked when they sent 2-3 fake txs ? 20:43:38 at which jeffro said it could be shuffled 20:44:12 any valid txs have to pay the fee 20:44:32 ? 20:44:32 https://github.com/monero-project/monero/blob/c2e3835223943732cd9f293d4e85da3a7b837a0e/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L944 20:44:56 the loop adding txs just exits 20:45:45 if you put the invalid tx at the end then all the first txs will get added to the tx-pool 20:46:38 yes, i assumed we were talking of trying to bloat computational time 20:47:40 if sending the bad txs first the rest of the txs are going to be dropped. so you could send them at the end instead so that it also lose time verifying the valid one 20:49:14 although yes you will have spent time, the txs are still valid so no different than receiving a valid tx on its own 20:49:25 the tx is still added to the pool and has to pay a fee 20:49:41 💡 very true lol 21:08:32 This isn't just a theoretical risk. PirateChain had severe chainsplits when it was hit with tx spam because verification time of Zcash-Sapling txs is high: https://web.archive.org/web/20230803171107/https://old.reddit.com/user/SignificantRoof5656/comments/15h9reh/pirate_chains_045_spam_attack_2_months_later/ 21:10:35 AFAIK, PirateChain's problem was too many _valid_ tx at very low tx fee. What is being discussed with FCMP `MAX_INPUTS` is defense against invalid txs, since it is "assumed" that Monero's fee structure protects against valid tx spam that would cause node instability. 21:12:09 > FAUSA's impact on mining was significant and immediately apparent. At times, up to 80% or more of the network's total hashrate was dropped, but this number stabilized at approximately 60%. This "lost" hashrate was unable to keep up with the blocks from other miners, resulting in at least 3 distinct and competing chains which I was able to identify. At some points, some of the sl ow miners were able to catch up with the main chain, only to split off again soon after. The numerous forks relatively quickly re-established consensus after the conclusion of FAUSA. 21:32:00 Can't wait for stressnet this may to start placing bet on if its so over 23:17:34 Rucknium: do you know off hand what the Sapling verification times are ? 23:52:11 No