For some time now I get "wrong share" / "cannot find job #" / "wrong hash #" errors in xmrig-proxy

is this updated needed ? what does it do ? : xmrig/xmrig #3067/commits/45061f40d807d6ac7ff065eba468c7bb0dbb6e7e

not all my miners are affected

sech1 ^

wrong channel

?

#monero-dev is not a place to ask about xmrig

make a github issue

kk

don't have github account to ask

i thought some dev could tell me if this update is needed for mining

devs told me i won't need to update my miners before the hard fork

you definitely need the latest release to keep mining

due to this update ?

yes

if you mine solo

if you mine to a pool, it shouldn't matter

but better update anyway

ok

thx

Hello everyone

hi

oh, it's moneromoooo!

moneromoooo: can I get a review of monero-project/monero #8673 ?

do you still stand by your comment about not removing the definition with the declaration?

we discussed this so often in the past lol i think it's best if you apply it to the debian package

selsta: okay, I've submitted the patch to debian. I'm just a bit curious why it hasn't been better documented or resolved.

like I said yesterday, I have never heard of a compiler getting killed because of an unused variable, but I also don't use debian

it's gcc's -Wunused-but-set-variable

along with treat warnings as errors

the compiler stops due to that, the killed is just an artifact of the stoppage

I corrupted a wallet cache doing a force reboot, now I get an error "Error: failed to load wallet: invalid signature". I need some information inside that cache. My idea was to compile a new version of monero-cli-wallet to bypass that signature check (so basically with a different boost::archive) and hope for the best. Am I a fool or could that

work?

hex editor?

my guess, and I don't know how the wallet works, is that the signature check indicates that there's been a partial write to some block. without all of the data, it's impossible to decrypt that block.

you may be able to decrypt and read all data up to but not including that block. it depends on what cipher is being used, and how the data is encoded.

-Werror is a stupid idea.

If you must have it due to distro rules, then this patch cannot hurt.

It's just busywork though.

cjac yeah, that was my idea, I'm going to check if it worth it

About the reason behind that var, I've not looked at it again since then. I don't really have the will to these days.

moneromoooo: I agree that -Werror is not a good idea when developing. It's good to see the warning that your change has caused. But if you're at the point of your release process that you're building a version that's ostensibly known good, there should be no warnings at that time.

-Werror can be good as a development tool to force you to address things early.

moneromoooo: that's reasonable. there's a lot of code in the repo.

After stuff is released, it's a bad idea since it means someone with slightly different headers may be unable to even build your stuff, even if such warnings are innocuous.

It'd be a good idea if you knew people would always build with the same env, but then you would not need -Werror in the firts place.

It'll also break if you use a new compiler that adds new checks.

Maybe the warnings do show something that's actually wrong, but then if you're not a hacker, what good does it do ?

For Debian, it might make sense, since they have hackers that are able to fix stuff (at least sometimes) but it also means you get to waste your time for stuff like this variable.

But then Debian maintainers can see warnings when building, without having to slavishly kill everyone while wasting time doing it.

So, -Werror is a stupid idea.

kill everything, by the way ^_^

er, every one.

Funny how a space changes meaning a lot here.

p2pool has been using -Werror since the very beginning :P

in additio to highest level of warnings

The one thing that really pisses me off with -Werror software is when I debug code. Often, it means some var will end up unused because I may have commented out part of the code.

And those idiotic build systems waste my time on purpose writing pointless stuff, commenting other lines/declarations, etc, basically doing more boilerplate to please the idiot, which will take more time later when undoing.

I've not hacked on p2pool yet so I don't hate you yet :)

Oh, and this is double plus rage inducing when the changes are in a header file, which means you waste WAY more time with compile cycles just because some moron wants you to comment a declaration because it's afraid of unused vars.

Oh, and that preposterous thing about warning when indent is wrong. WTF. It's not python.

I tend to add debug code with no indent so it's obvious later what needs removing.

But some idiotic -Werror will waste my time until I've located it in the build system and shived it.

It's basically a DoS attack masquerading as a good thing.

It's not like you cna't see the warnings in the first place.

(assuming there are not pages and pages of them, of course, it does happen in some code)

I learned a neat trick about unused stuff: just cast the identifier to void like `(void)unused_identifier;`

handy when your identifier is only used in an assert

It's about the same waste of time as doing: // int unused_identifier

well it works in production code too :)

The point is that you build your stuff, and the compiler tells you "no, add some pointless boiler plate first".

The actual edit is trivial, it's the wasted time of another cycle that's a monstrous attack on my time :P

Also I should add at this point that I am not vetoing adding -Werror to monero if most poeple want it. Given I'm not contributing much anymore. It's just, like, my opinion, man.

doesn't seem necessary

enable -Werror on release, not in debug :)

DataHoarder: no, that just makes unit test oriented development more of a pain

monero does not use many asserts, it's mainly unit tests

in game projects with Werror for example release has everything enabled, but there is a middle version without debug and with optimizations, but with most asserts, and without pedantic rules

that said unused variables tends to be one of the highest false positive there, at least, maybe enable Werror on CI on some projects might be cool

Looks like we are closing in on 2 weeks without much attention on the recent PRs I made for upstreaming seraphis_lib stuff. These PRs are very lightweight compared to what is coming - only around 300 line diff total and no new crypto. The seraphis_lib is a 65k line diff, so at this pace we will have seraphis sometime in the 2030s.

p.s. thanks to jeffro256[m] for taking a look at the PRs

hah

endogenic: looks like you are volunteering, that's great

looking forward to some reviews

hahah

i mean i am decent at c++ and know existing monero fairly intimately. so i'd be a good candidate except for my significant lack of availability

2030 is only 7 years away

but exit scam is 2023 hm

it would certainly help kill the "moner ohardforks all the time" fud

in a few months i might free up a bit

if it's all got tests etc. should it be "upstreamed".. what does that mean? should it not be its own repo.. libseraphis?

or some such

endogenic: I invite you to look at the PRs and the library, then maybe it will become clear.

code which, btw, has been in progress for over a year - did no one bother to look at it? I am suddenly very annoyed

i searched for seraphis in prs, also otherwise didnt find anything obviously relevant

not sure i understand

quick scan of crypto misc updates didnt seem like seraphis code

but it is described as part of the effort in the descr

btw the name didnt scream seraphis to me

and.. do i infer any seraphis changes arent going to be in a new repo bc they will be integrated with existing crypto/cryptonote?

because these are generic PRs that future PRs will depend on

yes, this is the branch I have been linking to continuously over the past year github.com/UkoeHB/monero/tree/seraphis_lib

sorry fwiw i have been scrambling to survive and complete lots of work. past couple yrs have been interesting

thats just me tho

no idea why people arent reviewing your code except a lack of visibility into its purpose

at the risk of sounding unfamiliar with your efforts, have you published the roadmap of PRs and code deps and sent it to hyc, vtnerd, ndorf and other people? mooo ofc

sorry for getting annoyed endogenic

there is no specific roadmap, these PRs are just preliminary work

have ppl like luigi weighed in on seraphis ?

and has a broader research community ?

I take the lack of complaints as a sign to keep going

it's not that

it's that we need someone to tell us "this is the right way to go"

there is no such person

sure there is

not here but sure they exist

anyway community overall can decide

people outside monero somehow know the best direction for monero?

sure

who is IN monero?

INvolved

we build on shoulders of those giants who can say things are right

just bc they dont chat on irc

doesnt mean theyre not in the work

so...

core can guide and inform

but we also need other informed parties to help us confirm the right way

i know a few

and have been involving them over this year

ok well I'm going to keep doing my thing - if someone shows up with something interesting to say I'll listen, otherwise I have work to do

:/

IMHO, for the best chance at input from the general research community, Seraphis needs formal security proofs. AFAIK, writing those proofs are on the roadmap.

thats only part of verifying if its the right path

hmm... I was getting 5280H/s with 18 threads, and I'm getting 5195H/s with 25. There should be plenty of memory for each thread to make use of. There's no disk usage. What might be the bottleneck here?

UkoeHB: anyway let me suggest tagging or prefixing yr PRs with "[seraphis]"

if i wasnt clear

and let's make a thing of talking about them during dev mtgs

that's how we used to do it

well

aside from having noethers

tho that also was a transient state

i have to say i find it out of place that my other questions were swept away too

make a checklist of whose approval you need to get on merging it and PR them

cjac: That is a good topic for #xmrmine:matrix.org or #monero . Short answer is probably CPU cache.

thanks, Rucknium[m]

endogenic: ok I added [seraphis] to emphasize their purpose

nice. confirmed. now i can search for seraphis AND discern btwn those marked explicitly and those which only say the word in text

and w0w so many

i'd amend your descr to add that it's not used *but* is a dep of such and such future code and is tested by X and or is otherwise functionally equiv and 'can be merged' etc but

with all this

continuous pr merging to core crypto code

there's an attack surface too

possibly also will lead to review fatigue

if none of it's used rn i would suggest making it all a plugin to existing code as a separate repo for now

personally

then it would get merged

no all the code has deep dependence on the monero repo

that doesnt matter

you can write it so that it consumes or wraps or whatever you want

does to me, I'm not spending 2+ weeks setting up a new repo

it takes 2 seconds

all your code gets copied

your diff is the merge

youre already working from a form

I don't get it - what's different from having a separate branch?

fork

right

the alternative is you make a lib

you can still code that so that it's adjacent

there isnt an issue

you still copy code

from monero

sigh

still don't get it

you can just as easily consume monero code as a lib

then you write your code to consume that

then voila

it's visible

not buried

if that takes you two weeks, then just maintain a fork and commit things to mainline which will get used

otherwise it's probably not time

sorry

I mean, if it's that easy then maybe you could do it?

if you bought me groceries and paid for my ct scans

ok

the monero repo is not really architected for librarizing

eh

it's not bad

wallet2 is the biggie

tho for me wallet2 is a 2 wk job

not a 1 day ? job like seraphis factorization

i mean dont get me wrong

expanding monero is the issue

that's what entropy means

it should be broken apart

but it's already fairly wel factored

the issue is how you add to it

that's a software engineer's art

if your solution is 'duplicate src/crypto', I have to disagree with that

that's not it

but it's a step in the right direction

we could pair program a bit

ordinarily

but i swear this has not been my year haha

i need a little while

Hi everyone