01:00:03 Revuo Monero Issue 228: February 16 - 23, 2025. https://www.revuo-xmr.com/weekly/issue-228/ 01:04:50 s 01:04:50 to federal Perkins V in 2018, the NSC includes, the 01:04:52 Biden Administration, natural… activities” 01:04:54 and may even better use 01:31:44 tweaker your username checks out, or AI? either way, stop please. 05:02:03 who runs/owns xmrchain.net ? 05:05:02 The crypto primitives that FCMP++ uses aren't from Zcash, it's from the Curve Trees paper 05:05:27 I mean all ideas build off of others, etc, etc but AFAIK there's no direct link 06:05:45 @ging 06:05:54 @gingeropolous:monero.social do you run xmrchain ? 11:02:03 lza_menace: yeah i help operate it. y? 11:57:35 lza_menace: , if your questioning the site responsiveness, yeah im aware. something is causing xmrblocks to have like 300-400% cpu usage, and top reports 66% memory usage (on 64g system), tho systemd-cgtop only reports 12G usage or so. 12:11:17 ok, just killed 500 connections from a singapore data center... so maybe it'll be happier 12:46:20 Hello 12:46:45 Is there a specific channel for asking for some help? :) 12:50:28 elaborate first 12:52:04 I found my wallet in 0.000000000000 and I remember mining with it in 2021 for some days 12:56:37 likely a simple issue, what wallet are you using? if monero-gui / cli - ensure its the latest version as there was a hardfork in 2022 august ... restore your wallet from 0.. use a local node or a functional remote one (not simple mode in gui) - if you need further assistance better to ask in #monero-support 12:57:21 Thankyou very much! 14:56:21 So when HF for dsa change? 14:57:42 jeffro256 14:58:56 never 14:59:01 monero will die with elliptic curve 14:59:10 elliptic curve are post-quantum secure 14:59:18 anything else is propaganda by le FBI 14:59:20 HF to 1. Deploy master branch ahead of FCMP 2. DSA: 2.1 Coinbase DSA 2.2 OSPEAD 15:00:03 I thought it was a 4 letter agency 15:01:32 HF to 1. Deploy master branch ahead of FCMP 2. DSA: 2.1 Coinbase DSA 2.2 OSPEAD 3. RandomX update 15:02:48 6 months? Discussion in next MRL meeting? 15:03:12 Mrl is for research 15:03:16 HF is dev 15:03:39 HF needs MRL inputs ? 15:05:43 I'd say push binaries for HF by may. Fork date by oct (4 months after binary release). then New FCMP++ binaries by january, to fork by july 2026 (6 months after binary release) 15:06:45 (i changed june -> may. I can count tho) 15:08:19 Imo its a good idea to run deploy master ahead of fcmp, and leave the fcmp HF to be focused on FCMP and carrot 15:08:46 Has been discussed by devs = next stop FCMP++ 15:09:02 Thats what she said 15:09:11 But she can never make her mind up 15:11:15 i think making fcmp hard fork too big might be a huge mistake. It wouldnt be the first time master was partially broken. (weve moved prs from master to release, only to be met with a lot of bug reports from use cases that went untested) 15:11:52 Even between 18.0.0 and now, weve had to re-release back-to-back twice 15:12:15 Master is a much bigger can of worms. And fcmp is an entirely different can 15:12:36 IMHO its safest to fork twice 15:14:57 Like.. theres a lot of stuff on master that isnt live on release. Better to release and test/fix it all before launching fcmp onto a broken foundation 15:28:30 What consensus changes would be pushed with a pre-FCMP HF besides RandomX update? or what's on the table 15:35:31 Sounds like testing is lacking 15:35:40 Re: an automated suite 15:40:53 So dsa change by July 2026? Of is that for fcmp 15:41:47 So dsa change by July 2026? Or is that for fcmp 15:43:10 Oh I see dsa + randomx change by oct 15:46:00 Cant test everything comorehensively. Some tests do catch a lot, but i think the most recent issue was bresking rpc-logic with a or that was on master for like 8 months before pushing it to relesse 15:47:17 Master uses a much more recent version of boost, c++17, a lot of bigger low lvl changes and even a lot of basic shit that was just never pushed to release 15:48:41 he have 1+hr of tests run on every commit / merge and pr 15:49:12 But that won't catch all edge cases (like active network traffic* 15:49:44 Same reason test/stsgenet doesnt catch everything. At the last hard fork we even dropped like 50tx from the txpool due to a fee mismatch 15:52:28 The most difficult bugs, once found, should be reproduced in an automated test. Should be doable given something like on-demand, cloud test environments. Can’t in-vision anything that cannot be reproduced. Not foreseen, yes. But still reproducible. 16:17:19 we have a test suite ... 16:17:32 ^ 16:17:42 Cuprate do its tests in 6 minutes 16:17:53 seethe about it 16:18:35 (probably biased, i didn't looked at the difference in the number of tests lol) 16:18:38 how long does it take to build cuprate 16:18:59 2 minutes 16:19:19 https://github.com/Cuprate/cuprate/actions/runs/13033762531/job/36358966167 16:20:10 https://github.com/monero-project/monero/actions/runs/13391357466/job/37400698949 16:24:17 Core tests are 30min, function tests rpc is abt 15min 16:26:13 cheating because files are cached from the previous checks :) 16:44:07 there are things that we could do to significantly speed up core tests, mooo opened a PR for it years ago but it got never merged 16:44:45 https://github.com/monero-project/monero/pull/5821 17:08:17 what was the ip? 17:08:51 just wondering. i was asking gbks for the source code to exploremonero because i want to host my own 19:20:15 chat my brain is working 19:20:25 i am developing an altcoin 19:20:32 right now i had a realisation 19:20:55 what if you ignore the idea of a TX and instead consider transfers 19:21:16 and then each block is its own tx 19:21:42 instantly saw the issue, zk-stark still needs to make range proof on each transfer to prevent malicious miners from stealing from blocks 19:23:57 infact more importantly, you cant be certain of anything 19:24:09 tx is a necessary abstractions bc you have to sign the tx 19:24:57 in xmr you sign with ring signature 20:13:05 cool jeffro256 I am checking out the forest and the trees 20:15:22 You never need a HF for DSA change unless you implement some sort of compression (like used in binning) which necessitates a change in the transaction format 20:16:31 Something like OSPEAD doesn't require a HF. A change in the number of ring members *would* require a HF 20:29:23 bruh you know xmr is very good when its difficult to think of any ways to improve it other than DAG for energy efficiency and scaling reasons 20:50:12 man, getinfo can kill a daemon 20:50:31 damn things been stuck for 5 minutes . wheres this info 20:55:06 damn kill 9 didn't do it either 21:03:08 Your pc is haunted 21:04:27 The problem is privacy buckets (an old user will reference new style decoys) 21:36:33 So dsa can be changed right now ? just pushing 0.18.5.0 and effective ringsize goes back up ? 21:37:56 no 21:38:01 Even with that users with new dsa will have a better ringsize than 4? 21:38:02 yes and no* 21:38:27 You can push dsa immediately, but it wont necessarily improve decoys unless everyone is using the new dsa 21:38:50 Old vs new decoys create more black marbles 21:39:06 So users can upgrade and get better effective ringsize than 4 21:39:20 Yah it will be a puddle 21:39:21 If you are spending new dsa and half of your decoys are old dsa, or vice versa 21:40:19 No. Example. If i use jeffros's coinbase segregation dsa, if only 1 of my decoys has the same dsa its very likely to be the change output from my prior tx 21:40:48 Yah that half output selection from recent spends is crappy allows easy attack too 21:41:12 You need all 16 decoys to update 21:41:33 Now,. heres the thing. the dsa isnt consensus, so a bad actor can spam bullshit decoys if they wanted to 21:42:22 They might be already doing that 😅 21:42:33 they can, for example, submit 500k tx that all use 15 nonsense transactions, and then your dsa is useless since youll reference those 500k bs decoys 21:42:48 Definitely. I pointed this out the other da 21:42:54 Make dsa a consensus ? 21:43:01 We have more weird number input/output tx than usual 21:43:23 I dont think its possible (as side from fcmp style) 21:43:51 Fcmp….. can’t wait and can’t keep hearing it 21:44:19 When you spend monero at a merchant, how often do you pay 8 people at once? Never 21:44:47 Those are mostly exchange payouts 21:45:12 so if you bought something at my store, and your ring had 25 decoys that were 3-15 output tx, its obvious that none of those are the real spend 21:45:31 15* decoys 21:45:36 for DSA to be consensus it needs to be deterministic which is *very* difficult and at this point even if possible not really worth the research 21:46:31 So what’s the consensus on fixing this current situation? 21:49:01 "Wait for fcmp" 21:49:10 Personally, i said what i said earlier 21:49:28 Let push hf binaries by may to hf by october 21:50:31 with master + randomx + ospead dsa + coinbase dsa 21:50:39 again asking if there are consensus changes other than RandomX? or is the idea mostly jsut to push a consensus change in order to force a DSA update? 21:51:31 The idea is to get people ready for fcmp hf and to split the amount of changes to keep fcmp hf mostly about fcmp, carrot etc 21:51:44 Force effective ring size back to normal 21:51:57 that's the DSA update 21:52:16 ofrnxmr: has other changes too 21:52:24 Consensus changes would be just randomx, i think 21:52:38 I just don't like the idea of pushing consensus changes that aren't in and of themselves worth it in order to force non-consensus updates onto people 21:53:13 Dsa update isn’t worth it ? 21:53:20 DSA update isn't consensus 21:54:17 its long past time that we pushed master to release 21:54:18 I'm not sure how important it is. I have been saying for awhile coinbase consolidations shouldn't even use rings or be used as decoyd 21:54:34 which.... actually *could* be a consensus change 21:54:49 well we are getting a point release soon regardless 21:54:58 We used to do it every 6 months, but because we dont have enough consensus changes necessary, we dont hard fork. 21:55:00 we COULD soft fork, but monero doesnt do that 21:55:41 soft fork doesn't help the DSA issue, the whole thing is wanting everyone on the same DSA 21:55:54 its business as usual there. Same ancient boost, same workarounds for old dependencies, same split development and incompatibilities between master and release 21:56:09 Out release branch is old and needs to be updated. 21:56:22 ah I see I guess I wasn't aware of that aspect 21:56:45 oh I see why now okay 21:58:04 okay so if i were gonna push for soft fork I would angle for randomx+ plus pushing coinbase spends to non-ring outputs or their own pool. can all be consensus, and it probably in itself very worthwhile. then if there's a better DSA, there can be a discussion about moving to that at the same time 21:58:13 okay so if i were gonna push for hard fork I would angle for randomx+ plus pushing coinbase spends to non-ring outputs or their own pool. can all be consensus, and it probably in itself very worthwhile. then if there's a better DSA, there can be a discussion about moving to that at the same time 21:58:33 just my 2c 22:01:35 The pushing coinbases to their own rings can probably be made to be consensus. The code works already, but jeffro closed the pr a few months ago 22:02:04 If not consensus, then at the very least a relay rule 22:12:16 I don't think randomX update is readu 22:12:23 I don't see why not consensus. the reason DSA is hard to make consensus is it's supposed to be picking things "randomly" and it's very hard to test for randomness versus say, did you just get an unusual result uhhh, randomly 22:12:59 tevador mia 22:15:04 from what I remember it was ready but could be wrong 22:21:37 It's possible to enforce a specific DSA by consensus: https://github.com/monero-project/research-lab/issues/87 22:24:35 IIRC, koe came up with the method. Basically, you take part of the existing tx data that is random uniform, and map it onto the distribution function of the DSA. So now you have random draws in the shape of the DSA. how do you make sure that once of the ring members are the real spend? You just increment the age of all the drawn ring members (to the left or the right) until on of 22:24:36 them lands on the real spend. At least, that's what I understand of it (koe was using computer science terms instead of stats terms to describe it). 22:47:15 Nioc, i thought rx update was ready like a yr ago, we just didnt feel necessary to update it for the h1 22:48:29 oh yeah I remember that, seems like the shift could really skew the distribution but idk 22:48:49 ofrnAI need clarification 22:49:15 I thought so but then there were questions = .shrug 22:57:36 from what I remember randomx update is mostly ready and sech1 offered to do the remaining work 23:08:58 so as I said done but not quite :D 23:09:43 not bad for a senile person 23:55:42 our yogurt night... 23:55:42 My nerves are fried from riding on this emotionally 23:55:44 ratified by local utilities.54 23:55:46 Title II of Dodd–Frank. 23:55:48 56. Norbert J. Michel 23:55:50 and Ann Rulon, Cato Institute 23:55:52 David Deptula, Mitchell Instituting 23:55:54 a three-fifths vote threshold. 23:55:56 Put 23:56:13 ACPI Error: AE_NOT_FOUND (20240827/psobject-220) 23:56:14 [ 0.270516] ACPI BIOS Error (bug): Failure creating, universe is outside us. Look at those flowers seems to have lost twenty-five years old in anime 23:56:16 lmfao 23:56:18 crispycat 23:56:53 chicagounbound.uchicago.edu/cgi/viewcontent.cgi?article=1153&context=journal_articles 23:57:03 wha 23:57:13 Confession of his early acquired by statutory requirement to allow others to join on 23:57:14 the same rules through loose 23:57:16 lending can have in droves. In addition, certain pregnancy, poor education-agencies/#_edn1 (last