00:00:37 that was at height 3471523 00:12:52 ofrnxmr: Done. Alt chains with more than one block might still omit too many blocks from display. Hard to know how it would look without an actual 2+ block alt chain to test, unless I try to inject some testing data. 00:37:47 Do we know if they are brosdcasting their second block at the same time as the first? 00:38:16 Looks like theyve always been the one to mine on top of their alt chain 01:47:15 ofrnxmr: I think so. Here's what I see in my txpool archive data from a well-connected node: 01:47:17 ```txt 01:47:19 block_hash prev_block_hash block_height block_timestamp block_receive_time block_receive_time_UTC 01:47:21 01:47:23 1: e6d074e0 770242fe 3471456 1754429537 1754429547 2025-08-05 21:32:27 01:47:25 2: a3673a1d aa0ca193 3471457 1754429550 1754429558 2025-08-05 21:32:38 01:47:27 ``` 01:47:56 It polls `monerod` about once per second (longer than a second if the txpool is very full and parsing takes longer). 01:50:00 If there were more than a second separation of broadcast of `aa0ca193` and `a37ald`, then the archiver should have recorded `aa0ca193` as a separate record instead of just as the `prev_block_hash` of `a3673a1d`. I think. 01:50:52 I instructed the archiver to require uniqueness on `block_hash`, not `block_height` in its database: https://github.com/Rucknium/xmrpeers/blob/main/R/txpool.R#L46-L54 01:51:25 Run your own txpool archiver: https://rucknium.github.io/xmrpeers/reference/index.html 01:54:22 did you get those blocks by syncing or did they get sent to you? 01:54:41 If you have the logs 01:56:19 I have default log level on this node. What log level would be necessary to capture that info? 01:57:59 I think it should show on default, you should get the message about being so many blocks behind and that you are syncing 01:58:35 Otherwise it would just show as a reorg without that bit before I think 01:58:58 ```txt 01:58:59 2025-08-05 21:32:37.636 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 3471456 01:59:01 2025-08-05 21:32:37.636 I id: 01:59:03 2025-08-05 21:32:37.636 I PoW: <69b4e16b0cd69c6b66411be6eba47c0b8d3fd84bfd78be33c7fb8b0000000000> 01:59:05 2025-08-05 21:32:37.636 I difficulty: 611843177366 01:59:07 2025-08-05 21:32:37.677 I ###### REORGANIZE on height: 3471456 of 3471456 with cum_difficulty 493270429806485498 01:59:09 2025-08-05 21:32:37.677 I alternative blockchain size: 2 with cum_difficulty 493271042868135659 01:59:11 2025-08-05 21:32:37.771 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 3471456 01:59:13 2025-08-05 21:32:37.771 I id: 01:59:15 2025-08-05 21:32:37.771 I PoW: <42393ff85051782db458f15d1a893c2eb0e4eb4cb626d36dcf1e080000000000> 01:59:17 2025-08-05 21:32:37.771 I difficulty: 611843177366 01:59:19 ^ This is what I have 02:00:26 Nothing before that about being behind? 02:00:38 No. 02:01:39 About 135 inbound and 12 outbound connections. 02:03:17 That last line shows you synced the blocks they were not sent to you in a broadcast: https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L1619 02:04:37 I am definitely seeing more of the `Synced X/X` messages in the last 24 hours, in the log, than usual. 02:06:52 Shooting themselves in the foot with the slow block propagation method then 14:38:14 I may be a few minutes late to the meeting today, since I have an appointment just before. 15:01:54 MRL meeting in this room in two hours. 17:00:26 Meeting time! https://github.com/monero-project/meta/issues/1250 17:00:33 1) Greetings 17:00:39 Hi 17:00:45 Hello 17:00:46 👋 17:00:48 Hello 17:01:38 *waves* 17:02:23 2) Updates. What is everyone working on? 17:04:37 me: Launched https://moneroconsensus.info/ , which visualizes orphaned blocks and alternative chains, which would tend to appear with greater frequency if a mining pool with a large hashpower share used a selfish mining strategy. Working on adding to the web app by implementing trustless hashpower estimation based on Ozisik, Bissias, & Levine (2017) "Estimation of Miner Hash Rates and Consensus on Blockchains" https://arxiv.org/abs/1707.00082 17:04:52 Me: lwsf and monero_c are working, finally 17:04:56 Howdy 17:05:07 Also looking at some other bugs 17:05:13 [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) thanks for setting up that site 17:05:15 me (repeating from the NWLB meeting Monday): ofrnxmr has been sharing solid bug reports on the FCMP++ integration, been working through them, submit a PR to get rid of initial block hash download on wallet restore from wallet2 + fix deep reorg handling + a slight refactor to wallet2 refresh + address issues ofrn/others have shared. Also got and shared current FCMP++ tx size and ve 17:05:17 rification time figures here: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3150754862 17:06:00 I did a preliminary review on the FCMP++ transaction sizes and verification times. Will be calculating actual fees. 17:06:01 Have completed the sanity median change. It can work with minimal wallet impact. 17:07:11 The verification time can be taken care of with the multiple minimum node relay level based on size alone 17:08:14 There is no case for weights outside of the non consensus changes in the membership proofs 17:08:37 Otherwise just use actual size 17:10:28 3) [Proposed Veridise reviews of Helioselene](https://gist.github.com/SamsungGalaxyPlayer/981e8281b91b49901f516eec54ee3c4d). 17:11:49 still working on monerosim. focusing on distributed block production 17:11:49 Hey all, we received a quote to review the helioselene library that won the recent contest 17:12:33 and a similar quote to provide additional documentation to explain why the helios/selene curve selection is safe in this application 17:12:58 the details are in the gist, and I am here to answer any questions 17:13:55 I believe that Veridise is especially skilled for the library project. Instead of just a review (which they will also do), they will do formal verification 17:14:24 for the curve selection, I believe that they are skilled, though others are skilled for that as well. I checked with a few others and they don't have favorable availability 17:17:01 This is modified w.r.t. other low hanging fruit and with an optimized impl of the non-optimized binary GCD. It isn't scoped to include any impl of the optimized GCD nor Rafael's BY inversion at this time. IMO, ideally we'd do the second impl properly, fairly compare the second and third, then move forward, but that'd take me three work days and I do not have the bandwidth. That's why, despite a slower than optimal inversion discussion, we're still discussing moving forward now (as I synced with jberman and jeffro a week ago, though jeffro didn't directly give a reply). 17:17:59 For curve selection, I do like Veridise but not so much I would say no to other competent candidates. Expanding a bit, 17:18:25 tevador proposed Helios/Selene. I verified the choice back in the day. 17:18:34 We're here now, with this optimized impl. 17:19:54 More efficient curve choices are possible. We have a 127-bit Crandall constant, 128-bit when 256-bit aligned. I personally believe a 127-bit constant (when aligned) could be marginally more efficient, and a 104-bit constant would be *notably faster* on certain architectures. 17:20:12 The contest revealed some of this insight, for clarity on timelinem 17:20:39 But more efficient curves will take longer to find and Helios/Selene was the best choice prior. I don't find it necessary nor reasonable to start a new hunt at this time. 17:21:01 So we should get external review of the choice of curve, to tie everything up in a nice bow, and that's the second quote from Veridise. 17:21:05 Those choices would be baked into consensus, right? 17:21:20 But also, Helios/Selene is embedded entirely in the FCMP and can be trivially replaced in a new HF. 17:21:22 After the hard fork 17:21:52 Impl isn't in consensus. Curve choice is. You can skip validating FCMP proofs to avoid requiring Helios/Selene. It has no other contamination. 17:22:03 I think the ideal time to hunt for one would have been before the contest. Which is hard because the contest revealed some of these possibilities more clearly. I think helios/selene does the job, and swapping it out now would cause more hard (delay) than benefit 17:22:07 It's not like outputs will now be on Helios or so. 17:22:24 It really is just like if we HFd to a more efficient membership proof, to change the curve 17:22:32 *harm not hard 17:22:40 *caveats incurred by the fact we're baking the tree root into the header AFAIK, but eh, it's all fine 17:23:01 Yeah. It's optimally a few percent faster, but an extra month of delay. 17:23:27 I'm presenting everything on the table, even when the reasons to delay are bade choices to follow up on. 17:24:07 I'm a definite +1 on this proposal as is, looks great to me 17:24:12 A few percentage points is not anything to go chasing after at this stage IMHO. Thanks for the info, though. 17:25:43 Separately I've been thinking about opening bounties as incentive for research exploration for tasks like searching for a potentially more optimal curve, so it wouldn't need to hold back anything on timeline front, and if someone finds something that demonstrates a significant perf boost, then we can decide to potentially proceed with it then 17:26:15 Astonishing that they will *formal* verification of code 17:26:43 rbrunner, see their last project here where they did something similar https://magicgrants.org/2025/08/05/Veridise-Gadgets-Circuit 17:26:53 Tasks like searching for a more optimal curve, optimizing prove(), and identifying and/or implementing further optimizations to helioselene 17:26:58 It's Veridise's field of expertise. They'll formally verify the algorithm, not the x86 assembly, though. 17:27:42 It's human review, and faith in compilers compiling, that will apply that result to our library. 17:28:06 plowsof has disallowed research bounties on bounties.monero.social 17:28:18 I actually don't think we should look for a new curve and believe we should halt future ECC development, fite me :C 17:28:40 But I'm for people making CCSs for faster impls 17:29:00 sgp: Thanks, interesting 17:29:44 They actually FOSSd their translator tool. Now any circuit on the framework I built can be entered into their tool, Picus. 17:29:50 rbrunner definitely give their report for that a read; they go into a lot of detail about how the translated it 17:30:09 This two-part Helioselene Review proposal by Veridise sounds good to me. 17:30:22 (I did not hand write the thousands of equations which is an FCMP. I wrote functions which call functions which expand to thousands of equations while automatically handling labeling and layout) 17:30:52 The reason I thought of a bounty is because it could potentially attract devs who don't have the bandwidth to commit to a CCS, but with a large enough bounty, could try their hand at it in free time or whatever. I had one specific candidate in mind for this (Fabrizio) 17:31:27 Heard with request we circle back on this jberman 17:32:31 jeffro256: any feedback on these quotes? 17:32:35 For the little I can really judge, I am also ok with the proposal 17:33:12 Also, FWIW, tevador proposed multiple curves before the contest. Helios/Selene was the best. 17:33:40 The comments on a better curve is we can more specifically point to specific metrics and how it effects the current code. 17:34:00 That doesn't mean such a curve exists/is feasible to find. 17:34:13 I wouldn't say plowsof did, and i also thinks more about unsolicited (non mrl) bounties 17:35:57 IMHO, the conversation about research bounties on bounties.monero.social could be re-opened. I should have said that many people agreed that research bounties should be disallowed, and plowsof implemented it. 17:37:01 The problem with research bounties is verifying the quality of the work product and setting completion standards. 17:37:25 Maybe allow them only with consensus in this channel; they are difficult to judge and keep focused unfortunately 17:38:16 Anyway, that's all from me. I'll move forward with these quotes 17:38:22 Research -1s proof verification plz 17:38:23 +1 xmr 17:38:25 +2 xmr 17:38:27 +10 xmr 17:38:29 Hi, I have a chatgpt account, here's research. Money? 17:38:31 sgp_: Do you want to get loose consensus from MRL today about this? I think it would be OK to do so. 17:38:40 If possible, yes I would like loose consensus 17:39:05 I thought we already had it 17:39:14 Everyone who has expressed an opinion has expressed a favorable opinion. 17:39:20 Anyone else? 17:39:23 Is it not loose consensus until Rucknium officially declares it loose consensus 17:39:35 Lol 17:39:42 well, you need to draw the line somewhere :) 17:39:57 Can it be a curve /s 17:40:15 This is actually one of the few things that the chair should do. Unless we want to bootstrap this idea. 17:40:22 Hey, I don't mind, I just thought we had it and I think you thought we did too 17:40:37 (Hence why you said you'd move forward) 17:40:43 Rucknium: sure :p 17:40:57 I mean, the chair shouldn't do much in these types of meetings, but this is one of the few duties, arguably. 17:41:43 I see loose consensus here in favor of "Helioselene Review" by Veridise for 36,250 USD equivalent or less https://gist.github.com/SamsungGalaxyPlayer/981e8281b91b49901f516eec54ee3c4d 17:42:15 ty ty, I'll get these started asap then 17:42:17 kayabanerve: Don't tell them about that time I threatened to bring out Robert's Rules of Order in a MAGIC Monero Fund meeting :P 17:43:01 Thanks everyone for your work and input on these reviews and audits. 17:43:07 4) [Transaction volume scaling parameters after FCMP hard fork](https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). 17:43:18 sgp_: swears by those 17:43:25 Maybe we should employ them? 17:44:30 I think SGP misclicked the thumbs down by accident with how excited they were. 17:44:51 /s, onto scaling? 17:45:00 Ok 17:45:37 I went over the TX sizes and verification times 17:46:59 jberman @jberman:monero.social: Can you bring your link down, please? 17:47:15 https://github.com/seraphis-migration/monero/issues/44#issuecomment-3150754862 17:47:41 Thank you 17:48:02 Two things are apparent 17:48:03 1) Changing the minimum node relay fee based upon transmission size does take care of the verification time issues 17:48:05 2) We should limit the use of transcription weights to the membership proofs and only to address non consensus changes in size 17:48:44 Otherwise just use the actual size 17:49:18 I'm against actual size because of how actual size is dependent on VarInts. 17:49:51 Estimating the weight impacts the fee impacts the TX size requires re-estimating the weight impacts the fee... 17:50:37 Doos this just apply to the membership proofs? 17:50:57 I'd prefer a simple formula based on inputs, outputs, TX extra, even if it is effectively the TX size for the number it outputs. 17:51:04 No, the fee is a VarInt. 17:52:29 I made we can use fixed weights based upon a set of initial size calculations 17:52:46 It's a really stupid annoyance that *can* be replaced by a single-pass algorithm but that would cause a fingerprint 17:53:28 Then apply it based upon inputs, outputs, tx extra 17:53:37 Stupid question: We can't just serialize a little bit differently and drop those VarInts? 17:53:48 I see no problem with that 17:54:37 What I am against is building a verification time surcharge on the tx weight 17:56:15 I don't recall fee being a varint being that big of an issue, you estimate close to get actual size and the fee only has to be nudged by minimal amount 17:56:55 It is gross because both lwsf and wallet2 do a multi pass for fee calculation, but it's not terrible 17:58:23 The idea would be to use estimated fixed weights that are close enough instead of actual size to simply the wallet calculations 17:58:32 I am fine with that 17:59:32 Simplifying is very welcome IMHO 17:59:47 So is there a loose consensus on this weight approach? 18:00:39 vtnerd: The fact the calculation depends on the result of the calculation is gross. The practical issue is whoever doesn't perform a recursive calculation will have observably different results on the block chain, allowing identifying the wallet used. 18:00:59 I'm against removing the clawback if we allow 128 inputs. 18:01:01 I'm fine with it. jeffro256 's code already does it fwiw and it's pretty clean 18:01:41 would this be, within a fre tier, a fixed fee per input? (+ extra for txextra) 18:01:46 Fee* tier 18:01:48 A 65 input TX will take as long to verify as a 128 input TX, and only benefits from batch verification if other 65+ input TXs are present. 18:01:55 The fee will be at least 200x higher 18:01:57 tbc, I'm fine with the approach to determine weight based on n inputs, no outputs, and extra len 18:01:59 n outputs* 18:02:01 So unless we limit the inputs to 8/16... 18:02:10 For 128 inputs 18:02:51 But compared to 65 inputs, which has the same verification time? 18:02:58 I am actually in favour of limiting input to 16 or even 8 18:03:00 the 8 inputs is already a pita on my testnet 18:03:34 Yes, but unfortunately it seems at large, the plan is to not YET limit the inputs so. 18:03:52 I think we need the clawback because of that decision. 18:04:16 TBC, I'd love to limit the inputs and simplify out the clawback, later moving to indistinguishability. 18:04:28 I will be calculating fees for the table up to 128 inputs. This may give us a better idea 18:04:46 But the vibe I have now is that we will only limit the amount of inputs when we mandate the amount of inputs. 18:04:58 I believe that to be a poor decision, but it is a decision. 18:05:21 Like, we can at least limit to 32 now so people do have to be more mindful w.r.t. aggregation 18:05:28 It takes into account the actual size and the additional fee level on node relay to make the larger size scale 18:05:32 That way, we don't immediately jump from 128 to 8. 18:05:37 65 input tx is taking 2.17s to verify, and is 80k bytes. 128 input tx is taking 3.44s to verify, and is 152k bytes 18:06:22 Hm. That's not as immediately expected. They should share an MSM size.... 18:06:25 Both would attract the maximum fee for scaling 18:06:37 Oh. Right. The batch FCMP isn't perfectly aligned to powers of 2 anymore. 18:06:45 200x minim 18:06:47 Sorry, jberman, how's 50 and 140? 18:06:56