Revuo Monero Issue 228: February 16 - 23, 2025. revuo-xmr.com/weekly/issue-228

<t​weaker:calitabby.net> s

<t​weaker:calitabby.net> to federal Perkins V in 2018, the NSC includes, the

<t​weaker:calitabby.net> Biden Administration, natural… activities”

<t​weaker:calitabby.net> and may even better use

tweaker your username checks out, or AI? either way, stop please.

<l​za_menace:monero.social> who runs/owns xmrchain.net ?

<j​effro256:monero.social> The crypto primitives that FCMP++ uses aren't from Zcash, it's from the Curve Trees paper

<j​effro256:monero.social> I mean all ideas build off of others, etc, etc but AFAIK there's no direct link

<l​za_menace:monero.social> @ging

<l​za_menace:monero.social> @gingeropolous:monero.social do you run xmrchain ?

<g​ingeropolous:monero.social> lza_menace: yeah i help operate it. y?

<g​ingeropolous:monero.social> 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.

<g​ingeropolous:monero.social> ok, just killed 500 connections from a singapore data center... so maybe it'll be happier

Hello

Is there a specific channel for asking for some help? :)

elaborate first

I found my wallet in 0.000000000000 and I remember mining with it in 2021 for some days

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

Thankyou very much!

<e​longated:matrix.org> So when HF for dsa change?

<o​frnxmr:xmr.mx> jeffro256

<s​yntheticbird:monero.social> never

<s​yntheticbird:monero.social> monero will die with elliptic curve

<s​yntheticbird:monero.social> elliptic curve are post-quantum secure

<s​yntheticbird:monero.social> anything else is propaganda by le FBI

<o​frnxmr:xmr.mx> HF to 1. Deploy master branch ahead of FCMP 2. DSA: 2.1 Coinbase DSA 2.2 OSPEAD

<o​frnxmr:xmr.mx> I thought it was a 4 letter agency

<o​frnxmr:xmr.mx> HF to 1. Deploy master branch ahead of FCMP 2. DSA: 2.1 Coinbase DSA 2.2 OSPEAD 3. RandomX update

<e​longated:matrix.org> 6 months? Discussion in next MRL meeting?

<o​frnxmr:xmr.mx> Mrl is for research

<o​frnxmr:xmr.mx> HF is dev

<e​longated:matrix.org> HF needs MRL inputs ?

<o​frnxmr:xmr.mx> 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)

<o​frnxmr:xmr.mx> (i changed june -> may. I can count tho)

<o​frnxmr:xmr.mx> Imo its a good idea to run deploy master ahead of fcmp, and leave the fcmp HF to be focused on FCMP and carrot

Has been discussed by devs = next stop FCMP++

<o​frnxmr:xmr.mx> Thats what she said

<o​frnxmr:xmr.mx> But she can never make her mind up

<o​frnxmr:xmr.mx> 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)

<o​frnxmr:xmr.mx> Even between 18.0.0 and now, weve had to re-release back-to-back twice

<o​frnxmr:xmr.mx> Master is a much bigger can of worms. And fcmp is an entirely different can

<o​frnxmr:xmr.mx> IMHO its safest to fork twice

<o​frnxmr:xmr.mx> 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

<m​onero.arbo:matrix.org> What consensus changes would be pushed with a pre-FCMP HF besides RandomX update? or what's on the table

<a​remor:matrix.org> Sounds like testing is lacking

<a​remor:matrix.org> Re: an automated suite

<e​longated:matrix.org> So dsa change by July 2026? Of is that for fcmp

<e​longated:matrix.org> So dsa change by July 2026? Or is that for fcmp

<e​longated:matrix.org> Oh I see dsa + randomx change by oct

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> he have 1+hr of tests run on every commit / merge and pr

<o​frnxmr:xmr.mx> But that won't catch all edge cases (like active network traffic*

<o​frnxmr:xmr.mx> 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

<a​remor:matrix.org> 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.

<o​frnxmr:xmr.mx> we have a test suite ...

<o​frnxmr:xmr.mx> ^

<s​yntheticbird:monero.social> Cuprate do its tests in 6 minutes

<s​yntheticbird:monero.social> seethe about it

<s​yntheticbird:monero.social> (probably biased, i didn't looked at the difference in the number of tests lol)

<o​frnxmr:xmr.mx> how long does it take to build cuprate

<s​yntheticbird:monero.social> 2 minutes

<s​yntheticbird:monero.social> github.com/Cuprate/cuprate/actions/runs/13033762531/job/36358966167

<o​frnxmr:xmr.mx> github.com/monero-project/monero/ac…ns/runs/13391357466/job/37400698949

<o​frnxmr:xmr.mx> Core tests are 30min, function tests rpc is abt 15min

<b​oog900:monero.social> cheating because files are cached from the previous checks :)

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

<l​za_menace:monero.social> what was the ip?

<l​za_menace:monero.social> just wondering. i was asking gbks for the source code to exploremonero because i want to host my own

chat my brain is working

i am developing an altcoin

right now i had a realisation

what if you ignore the idea of a TX and instead consider transfers

and then each block is its own tx

instantly saw the issue, zk-stark still needs to make range proof on each transfer to prevent malicious miners from stealing from blocks

infact more importantly, you cant be certain of anything

tx is a necessary abstractions bc you have to sign the tx

in xmr you sign with ring signature

<i​mprevisto:matrix.org> cool jeffro256 I am checking out the forest and the trees

<j​effro256:monero.social> 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

<j​effro256:monero.social> Something like OSPEAD doesn't require a HF. A change in the number of ring members *would* require a HF

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

man, getinfo can kill a daemon

damn things been stuck for 5 minutes . wheres this info

damn kill 9 didn't do it either

<o​frnxmr:xmr.mx> Your pc is haunted

<o​frnxmr:xmr.mx> The problem is privacy buckets (an old user will reference new style decoys)

<e​longated:matrix.org> So dsa can be changed right now ? just pushing 0.18.5.0 and effective ringsize goes back up ?

<o​frnxmr:xmr.mx> no

<e​longated:matrix.org> Even with that users with new dsa will have a better ringsize than 4?

<o​frnxmr:xmr.mx> yes and no*

<o​frnxmr:xmr.mx> You can push dsa immediately, but it wont necessarily improve decoys unless everyone is using the new dsa

<o​frnxmr:xmr.mx> Old vs new decoys create more black marbles

<e​longated:matrix.org> So users can upgrade and get better effective ringsize than 4

<e​longated:matrix.org> Yah it will be a puddle

<o​frnxmr:xmr.mx> If you are spending new dsa and half of your decoys are old dsa, or vice versa

<o​frnxmr:xmr.mx> 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

<e​longated:matrix.org> Yah that half output selection from recent spends is crappy allows easy attack too

<o​frnxmr:xmr.mx> You need all 16 decoys to update

<o​frnxmr:xmr.mx> Now,. heres the thing. the dsa isnt consensus, so a bad actor can spam bullshit decoys if they wanted to

<e​longated:matrix.org> They might be already doing that 😅

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> Definitely. I pointed this out the other da

<e​longated:matrix.org> Make dsa a consensus ?

<o​frnxmr:xmr.mx> We have more weird number input/output tx than usual

<o​frnxmr:xmr.mx> I dont think its possible (as side from fcmp style)

<e​longated:matrix.org> Fcmp….. can’t wait and can’t keep hearing it

<o​frnxmr:xmr.mx> When you spend monero at a merchant, how often do you pay 8 people at once? Never

<e​longated:matrix.org> Those are mostly exchange payouts

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 15* decoys

<m​onero.arbo:matrix.org> 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

<e​longated:matrix.org> So what’s the consensus on fixing this current situation?

<o​frnxmr:xmr.mx> "Wait for fcmp"

<o​frnxmr:xmr.mx> Personally, i said what i said earlier

<o​frnxmr:xmr.mx> Let push hf binaries by may to hf by october

<o​frnxmr:xmr.mx> with master + randomx + ospead dsa + coinbase dsa

<m​onero.arbo:matrix.org> 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?

<o​frnxmr:xmr.mx> 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

<e​longated:matrix.org> Force effective ring size back to normal

<m​onero.arbo:matrix.org> that's the DSA update

<e​longated:matrix.org> ofrnxmr: has other changes too

<o​frnxmr:xmr.mx> Consensus changes would be just randomx, i think

<m​onero.arbo:matrix.org> 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

<e​longated:matrix.org> Dsa update isn’t worth it ?

<m​onero.arbo:matrix.org> DSA update isn't consensus

<o​frnxmr:xmr.mx> its long past time that we pushed master to release

<m​onero.arbo:matrix.org> 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

<m​onero.arbo:matrix.org> which.... actually *could* be a consensus change

<m​onero.arbo:matrix.org> well we are getting a point release soon regardless

<o​frnxmr:xmr.mx> We used to do it every 6 months, but because we dont have enough consensus changes necessary, we dont hard fork.

<o​frnxmr:xmr.mx> we COULD soft fork, but monero doesnt do that

<m​onero.arbo:matrix.org> soft fork doesn't help the DSA issue, the whole thing is wanting everyone on the same DSA

<o​frnxmr:xmr.mx> its business as usual there. Same ancient boost, same workarounds for old dependencies, same split development and incompatibilities between master and release

<o​frnxmr:xmr.mx> Out release branch is old and needs to be updated.

<m​onero.arbo:matrix.org> ah I see I guess I wasn't aware of that aspect

<m​onero.arbo:matrix.org> oh I see why now okay

<m​onero.arbo:matrix.org> 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

<m​onero.arbo:matrix.org> 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

<m​onero.arbo:matrix.org> just my 2c

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> If not consensus, then at the very least a relay rule

I don't think randomX update is readu

<m​onero.arbo:matrix.org> 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

tevador mia

<m​onero.arbo:matrix.org> from what I remember it was ready but could be wrong

<r​ucknium:monero.social> It's possible to enforce a specific DSA by consensus: monero-project/research-lab #87

<r​ucknium:monero.social> 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 <clipped message>

<r​ucknium:monero.social> 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).

<o​frnxmr:xmr.mx> Nioc, i thought rx update was ready like a yr ago, we just didnt feel necessary to update it for the h1

<m​onero.arbo:matrix.org> oh yeah I remember that, seems like the shift could really skew the distribution but idk

ofrnAI need clarification

I thought so but then there were questions = .shrug

from what I remember randomx update is mostly ready and sech1 offered to do the remaining work

so as I said done but not quite :D

not bad for a senile person

<t​weaker:calitabby.net> our yogurt night...

<t​weaker:calitabby.net> My nerves are fried from riding on this emotionally

<t​weaker:calitabby.net> ratified by local utilities.54

<t​weaker:calitabby.net> Title II of Dodd–Frank.

<t​weaker:calitabby.net> 56. Norbert J. Michel

<t​weaker:calitabby.net> and Ann Rulon, Cato Institute

<t​weaker:calitabby.net> David Deptula, Mitchell Instituting

<t​weaker:calitabby.net> a three-fifths vote threshold.

<t​weaker:calitabby.net> Put

<t​weaker:calitabby.net> ACPI Error: AE_NOT_FOUND (20240827/psobject-220)

<t​weaker:calitabby.net> [ 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

<t​weaker:calitabby.net> lmfao

<t​weaker:calitabby.net> crispycat

<t​weaker:calitabby.net> chicagounbound.uchicago.edu/cgi/viewcontent.cgi?article=1153&context=journal_articles

<c​rispycat:calitabby.net> wha

<t​weaker:calitabby.net> Confession of his early acquired by statutory requirement to allow others to join on

<t​weaker:calitabby.net> the same rules through loose

<t​weaker:calitabby.net> lending can have in droves. In addition, certain pregnancy, poor education-agencies/#_edn1 (last