09:20:42 <ypavtv97lx[m]> For some time now I get "wrong share" / "cannot find job #" / "wrong hash #" errors in xmrig-proxy
09:20:55 <ypavtv97lx[m]> is this updated needed ? what does it do ? : https://github.com/xmrig/xmrig/pull/3067/commits/45061f40d807d6ac7ff065eba468c7bb0dbb6e7e
09:21:57 <ypavtv97lx[m]> not all my miners are affected
09:53:54 <plowsof11> sech1 ^
09:54:26 <sech1> wrong channel
09:55:07 <ypavtv97lx[m]> ?
09:55:36 <sech1> #monero-dev is not a place to ask about xmrig
09:55:42 <sech1> make a github issue
09:55:46 <ypavtv97lx[m]> kk
09:56:09 <ypavtv97lx[m]> don't have github account to ask
09:56:19 <ypavtv97lx[m]> i thought some dev could tell me if this update is needed for mining
09:56:46 <ypavtv97lx[m]> devs told me i won't need to update my miners before the hard fork
09:57:18 <sech1> you definitely need the latest release to keep mining
09:57:31 <ypavtv97lx[m]> due to this update ?
09:57:43 <sech1> yes
09:57:47 <sech1> if you mine solo
09:57:53 <sech1> if you mine to a pool, it shouldn't matter
09:58:04 <sech1> but better update anyway
09:58:09 <ypavtv97lx[m]> ok
09:58:12 <ypavtv97lx[m]> thx
15:47:08 <Bouska> Hello everyone
15:50:20 <moneromoooo> hi
15:51:52 <cjac> oh, it's moneromoooo!
15:55:54 <cjac> moneromoooo: can I get a review of https://github.com/monero-project/monero/pull/8673 ?
15:56:09 <cjac> do you still stand by your comment about not removing the definition with the declaration?
15:56:44 <selsta> we discussed this so often in the past lol i think it's best if you apply it to the debian package
15:58:18 <cjac> selsta: okay, I've submitted the patch to debian.  I'm just a bit curious why it hasn't been better documented or resolved.
15:59:42 <selsta> 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
16:00:49 <cjac> it's gcc's -Wunused-but-set-variable
16:00:58 <cjac> along with treat warnings as errors
16:02:56 <DataHoarder> the compiler stops due to that, the killed is just an artifact of the stoppage
16:04:06 <Bouska> 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
16:04:07 <Bouska> work?
16:05:29 <cjac> hex editor?
16:06:59 <cjac> 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.
16:07:31 <cjac> 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.
16:08:32 <moneromoooo> -Werror is a stupid idea.
16:09:27 <moneromoooo> If you must have it due to distro rules, then this patch cannot hurt.
16:09:37 <moneromoooo> It's just busywork though.
16:09:53 <Bouska> cjac yeah, that was my idea, I'm going to check if it worth it
16:12:33 <moneromoooo> 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.
16:12:44 <cjac> 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.
16:13:28 <moneromoooo> -Werror can be good as a development tool to force you to address things early.
16:13:55 <cjac> moneromoooo: that's reasonable.  there's a lot of code in the repo.
16:14:09 <moneromoooo> 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.
16:14:40 <moneromoooo> 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.
16:14:53 <moneromoooo> It'll also break if you use a new compiler that adds new checks.
16:15:16 <moneromoooo> Maybe the warnings do show something that's actually wrong, but then if you're not a hacker, what good does it do ?
16:16:11 <moneromoooo> 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.
16:16:53 <moneromoooo> But then Debian maintainers can see warnings when building, without having to slavishly kill everyone while wasting time doing it.
16:17:05 <moneromoooo> So, -Werror is a stupid idea.
16:17:47 <moneromoooo> kill everything, by the way ^_^
16:17:54 <moneromoooo> er, every one.
16:18:17 <moneromoooo> Funny how a space changes meaning a lot here.
16:27:55 <sech1> p2pool has been using -Werror since the very beginning :P
16:28:16 <sech1> in additio to highest level of warnings
16:42:16 <moneromoooo> 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.
16:43:11 <moneromoooo> 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.
16:43:42 <moneromoooo> I've not hacked on p2pool yet so I don't hate you yet :)
16:44:43 <moneromoooo> 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.
16:45:13 <moneromoooo> Oh, and that preposterous thing about warning when indent is wrong. WTF. It's not python.
16:45:30 <moneromoooo> I tend to add debug code with no indent so it's obvious later what needs removing.
16:46:03 <moneromoooo> But some idiotic -Werror will waste my time until I've located it in the build system and shived it.
16:46:11 * moneromoooo grumbles
16:46:41 <moneromoooo> It's basically a DoS attack masquerading as a good thing.
16:46:59 <moneromoooo> It's not like you cna't see the warnings in the first place.
16:47:15 <moneromoooo> (assuming there are not pages and pages of them, of course, it does happen in some code)
16:50:06 <UkoeHB> I learned a neat trick about unused stuff: just cast the identifier to void like `(void)unused_identifier;`
16:50:24 <UkoeHB> handy when your identifier is only used in an assert
16:50:48 <moneromoooo> It's about the same waste of time as doing: // int unused_identifier
16:51:07 <UkoeHB> well it works in production code too :)
16:51:11 <moneromoooo> The point is that you build your stuff, and the compiler tells you "no, add some pointless boiler plate first".
16:51:40 <moneromoooo> The actual edit is trivial, it's the wasted time of another cycle that's a monstrous attack on my time :P
16:53:49 <moneromoooo> 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.
16:55:07 <UkoeHB> doesn't seem necessary
16:57:13 <DataHoarder> enable -Werror on release, not in debug :)
16:58:39 <UkoeHB> DataHoarder: no, that just makes unit test oriented development more of a pain
16:59:03 <UkoeHB> monero does not use many asserts, it's mainly unit tests
17:00:32 <DataHoarder> 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
17:01:48 <DataHoarder> 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
17:14:12 <UkoeHB> 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.
17:15:58 <UkoeHB> p.s. thanks to jeffro256[m] for taking a look at the PRs
17:21:10 <endogenic> hah
17:24:42 <UkoeHB> endogenic: looks like you are volunteering, that's great
17:24:51 <UkoeHB> looking forward to some reviews
17:25:00 <endogenic> hahah
17:25:54 <endogenic> 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
17:26:44 <plowsof11> 2030 is only 7 years away 
17:27:11 <endogenic> but exit scam is 2023 hm
17:27:28 <hyc> it would certainly help kill the "moner ohardforks all the time" fud
17:29:20 <endogenic> in a few months i might free up a bit
17:31:28 <endogenic> if it's all got tests etc. should it be "upstreamed".. what does that mean? should it not be its own repo.. libseraphis?
17:31:32 <endogenic> or some such
17:38:57 <UkoeHB> endogenic: I invite you to look at the PRs and the library, then maybe it will become clear.
17:39:59 <UkoeHB> code which, btw, has been in progress for over a year - did no one bother to look at it? I am suddenly very annoyed
17:40:51 <endogenic> i searched for seraphis in prs, also otherwise didnt find anything obviously relevant
17:41:59 * endogenic sends hugs to koe
17:42:31 <UkoeHB> https://github.com/monero-project/monero/pulls/UkoeHB
17:43:32 <endogenic> not sure i understand
17:43:43 <endogenic> quick scan of crypto misc updates didnt seem like seraphis code
17:43:50 <endogenic> but it is described as part of the effort in the descr
17:44:04 <endogenic> btw the name didnt scream seraphis to me
17:44:42 <endogenic> and.. do i infer any seraphis changes arent going to be in a new repo bc they will be integrated with existing crypto/cryptonote?
17:44:49 <UkoeHB> because these are generic PRs that future PRs will depend on
17:45:35 <UkoeHB> yes, this is the branch I have been linking to continuously over the past year https://github.com/UkoeHB/monero/tree/seraphis_lib
17:46:08 <endogenic> sorry fwiw i have been scrambling to survive and complete lots of work. past couple yrs have been interesting
17:46:27 <endogenic> thats just me tho
17:46:49 <endogenic> no idea why people arent reviewing your code except a lack of visibility into its purpose
17:48:10 <endogenic> 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
17:48:28 <UkoeHB> sorry for getting annoyed endogenic 
17:48:41 <UkoeHB> there is no specific roadmap, these PRs are just preliminary work
17:49:43 <endogenic> have ppl like luigi weighed in on seraphis ?
17:49:57 <endogenic> and has a broader research community ?
17:50:44 <UkoeHB> I take the lack of complaints as a sign to keep going
17:50:55 <endogenic> it's not that
17:51:12 <endogenic> it's that we need someone to tell us "this is the right way to go"
17:51:23 <UkoeHB> there is no such person
17:51:28 <endogenic> sure there is
17:51:36 <endogenic> not here but sure they exist
17:52:02 <endogenic> anyway community overall can decide
17:52:03 <UkoeHB> people outside monero somehow know the best direction for monero?
17:52:07 <endogenic> sure
17:52:12 <endogenic> who is IN monero?
17:52:23 <UkoeHB> INvolved
17:52:39 <endogenic> we build on shoulders of those giants who can say things are right
17:52:50 <endogenic> just bc they dont chat on irc
17:52:57 <endogenic> doesnt mean theyre not in the work
17:53:03 <endogenic> so...
17:53:09 <endogenic> core can guide and inform
17:53:27 <endogenic> but we also need other informed parties to help us confirm the right way
17:53:30 <endogenic> i know a few
17:53:37 <endogenic> and have been involving them over this year
17:54:33 <UkoeHB> 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
17:55:00 <endogenic> :/
17:56:31 <Rucknium[m]> 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.
17:56:51 <endogenic> thats only part of verifying if its the right path
17:58:08 <cjac> 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?
17:58:48 <endogenic> UkoeHB: anyway let me suggest tagging or prefixing yr PRs with "[seraphis]"
17:58:56 <endogenic> if i wasnt clear
17:59:30 <endogenic> and let's make a thing of talking about them during dev mtgs
17:59:37 <endogenic> that's how we used to do it
17:59:42 <endogenic> well
17:59:45 <endogenic> aside from having noethers
18:00:00 <endogenic> tho that also was a transient state
18:00:58 <endogenic> i have to say i find it out of place that my other questions were swept away too
18:01:28 <endogenic> make a checklist of whose approval you need to get on merging it and PR them
18:01:43 <Rucknium[m]> cjac: That is a good topic for #xmrmine:matrix.org  or #monero . Short answer is probably CPU cache.
18:02:53 <cjac> thanks, Rucknium[m] 
18:12:29 <UkoeHB> endogenic: ok I added [seraphis] to emphasize their purpose
18:15:23 <endogenic> nice. confirmed. now i can search for seraphis AND discern btwn those marked explicitly and those which only say the word in text
18:15:42 <endogenic> and w0w so many
18:17:27 <endogenic> 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
18:17:31 <endogenic> with all this
18:17:44 <endogenic> continuous pr merging to core crypto code
18:17:50 <endogenic> there's an attack surface too
18:18:03 <endogenic> possibly also will lead to review fatigue
18:18:35 <endogenic> if none of it's used rn i would suggest making it all a plugin to existing code as a separate repo for now
18:18:38 <endogenic> personally
18:18:45 <endogenic> then it would get merged
18:30:57 <UkoeHB> no all the code has deep dependence on the monero repo
18:31:50 <endogenic> that doesnt matter
18:32:04 <endogenic> you can write it so that it consumes or wraps or whatever you want
18:32:14 <UkoeHB> does to me, I'm not spending 2+ weeks setting up a new repo
18:32:24 <endogenic> it takes 2 seconds
18:32:31 <endogenic> all your code gets copied
18:32:39 <endogenic> your diff is the merge
18:33:36 <endogenic> youre already working from a form
18:33:37 <UkoeHB> I don't get it - what's different from having a separate branch?
18:33:37 <endogenic> fork
18:33:42 <endogenic> right
18:33:53 <endogenic> the alternative is you make a lib
18:34:06 <endogenic> you can still code that so that it's adjacent
18:34:12 <endogenic> there isnt an issue
18:34:21 <endogenic> you still copy code
18:34:24 <endogenic> from monero
18:34:36 <endogenic> sigh
18:35:15 <UkoeHB> still don't get it
18:35:16 <endogenic> you can just as easily consume monero code as a lib
18:35:34 <endogenic> then you write your code to consume that
18:35:36 <endogenic> then voila
18:35:38 <endogenic> it's visible
18:35:40 <endogenic> not buried
18:36:22 <endogenic> if that takes you two weeks, then just maintain a fork and commit things to mainline which will get used
18:36:30 <endogenic> otherwise it's probably not time
18:36:42 <endogenic> sorry
18:37:25 <UkoeHB> I mean, if it's that easy then maybe you could do it?
18:37:38 <endogenic> if you bought me groceries and paid for my ct scans
18:37:43 <endogenic> ok
18:37:49 <UkoeHB> the monero repo is not really architected for librarizing
18:37:53 <endogenic> eh
18:37:56 <endogenic> it's not bad
18:38:04 <endogenic> wallet2 is the biggie
18:38:15 <endogenic> tho for me wallet2 is a 2 wk job
18:38:31 <endogenic> not a 1 day ? job like seraphis factorization
18:38:41 <endogenic> i mean dont get me wrong
18:38:44 <endogenic> expanding monero is the issue
18:38:50 <endogenic> that's what entropy means
18:39:01 <endogenic> it should be broken apart
18:39:32 <endogenic> but it's already fairly wel factored
18:39:51 <endogenic> the issue is how you add to it
18:40:01 <endogenic> that's a software engineer's art
18:40:32 <UkoeHB> if your solution is 'duplicate src/crypto', I have to disagree with that
18:40:42 <endogenic> that's not it
18:40:49 <endogenic> but it's a step in the right direction
18:41:07 <endogenic> we could pair program a bit
18:41:08 <endogenic> ordinarily
18:41:15 <endogenic> but i swear this has not been my year haha
18:41:40 <endogenic> i need a little while
21:12:37 <DanielBurlacu[m]> Hi everyone
21:30:11 -xmr-pr- SChernykh opened pull request #8678: Refactored rx-slow-hash.c to make fast PoW verification possible [rele...
21:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8678
21:30:11 -xmr-pr- SChernykh opened pull request #8677: Refactored rx-slow-hash.c to make fast PoW verification possible
21:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8677