00:33:48 <m-relay> <0​001dev:matrix.org> what is best way to contact core dev team?
00:34:34 <m-relay> <o​ne-horse-wagon:monero.social> Guest 68.  Have you port forwarded 18080?
00:54:11 <m-relay> <j​effro256:monero.social> Is it related to a vulnerability ?
00:55:12 <m-relay> <j​effro256:monero.social> If so, use the Hackerone : https://hackerone.com/monero
06:18:48 <m-relay> <0​001dev:matrix.org> no. but is important
06:19:31 <m-relay> <0​001dev:matrix.org> jeffro256: is any contact except for luigi email shown on github?
06:22:30 <m-relay> <0​001dev:matrix.org> guest 68: windows 7 is out of security support. is not safe to run even on LAN. example: CVE-2024-30078
06:57:18 <m-relay> <r​brunner7:monero.social> 0001dev: If you mean with "core dev team" the devs that actually work on the codebase and are on top of developments: Well, this here is our channel / room. Seems to me you are already in the right place for any dev non-security related dev questions. What you write here will, sooner or later, get noticed by many such devs.
07:20:49 <m-relay> <r​brunner7:monero.social> Of course they are on Matrix.org ...
08:56:51 <m-relay> <o​ne-horse-wagon:monero.social> 0001dev: Current stats claim about 25% of windows users still use windows 7.  Excuse is their apps won't work with newer versions.
10:15:59 <m-relay> <r​brunner7:monero.social> one-horse-wagon, you may have to update your info, Windows 7 probably stands at a few percents left: https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide
10:49:30 <m-relay> <o​ne-horse-wagon:monero.social> You're right.  Thank you.
10:50:51 <m-relay> <o​ne-horse-wagon:monero.social> Was looking at old numbers.
13:06:00 <Bungo> o/ interested in hobby projecting an xmr based (clone+mods) coin, WOW is fun, enjoy the approach. Have developed hobby ERC20 tokens before, looking at the github and mastering monero, not overly skilled in C languages but curious. Wondering if anyone would recommend any specific resources outside of git, mastering xmr, and reddit posts for a
13:06:01 <Bungo> hobbyist?
13:06:47 <m-relay> <s​yntheticbird:monero.social> Zero to Monero 2.0 is a little outdated but is still a valuable resource
13:07:00 <m-relay> <s​yntheticbird:monero.social> for technical understanding
13:07:57 <Bungo> lovely thanks
14:32:40 <m-relay> <j​effro256:monero.social> The mininero implementation can be helpful for understanding how the math is implemented (just don't look at the old script file like I did)
18:46:34 <selsta> woodser: just to confirm, this is 100% traced back to ubuntu 22.04 used for depends and no other issue? https://github.com/monero-project/monero/issues/9371
18:47:18 <selsta> what i mean is the same user built from 20.04 and 22.04 and one worked and the other didn't?
18:57:45 <sech1> Is only cross-compilation broken?
20:13:32 <m-relay> <0​xfffc:monero.social> quick question, when we do `flush_txpool`,  we just need to clean the txpool right? do we need go through `parse_and_validate_tx_from_blob`?
20:16:06 <m-relay> <0​xfffc:monero.social> https://matrix.monero.social/_matrix/media/v1/download/monero.social/DaocorQaHKfEmSnkcSnNswkr
20:16:26 <m-relay> <0​xfffc:monero.social> this is profiling results for `flush_txpool` command.
20:27:45 <m-relay> <v​tnerd:monero.social> Yeah it shouldn't be needed. Looks like it was just done as a convenience for using take_tx
20:29:32 <m-relay> <0​xfffc:monero.social> vtnerd: thanks. this is another optimization we can implement then.
20:33:53 <moneromooo> Just make sure you only do it for the case of flushing the whole pool.
20:35:04 <m-relay> <s​yntheticbird:monero.social> what tool are you using exactly?
20:35:43 <m-relay> <0​xfffc:monero.social> https://github.com/google/orbit it is a basically fancy frontend for `perf`.
20:45:57 <m-relay> <w​oodser:monero.social> selsta yes I'm sure the binaries I cross-compile from 20.04 are incompatible with the binaries from 22.04
20:46:32 <m-relay> <0​xfffc:monero.social> is there any extra reason that we do use `validate` when we are starting monerod? this is `O(n^2)` and not efficient.
20:46:44 <m-relay> <0​xfffc:monero.social> take a look at this call order, starting from here, call order for our `O(n^2)` operation:
20:46:46 <m-relay> <0​xfffc:monero.social> 1. https://github.com/monero-project/monero/blob/cc73fe71162d564ffda8e549b79a350bca53c454/src/cryptonote\_core/tx\_pool.cpp#L1802
20:46:48 <m-relay> <0​xfffc:monero.social> 2. https://github.com/monero-project/monero/blob/cc73fe71162d564ffda8e549b79a350bca53c454/src/cryptonote\_core/tx\_pool.cpp#L632
20:46:50 <m-relay> <0​xfffc:monero.social> 3. https://github.com/monero-project/monero/blob/cc73fe71162d564ffda8e549b79a350bca53c454/src/cryptonote\_core/tx\_pool.cpp#L756
20:47:34 <selsta> if someone updates monerod and the txpool has different rules you want to validate it first I assume
20:47:35 <m-relay> <0​xfffc:monero.social> ( thanks to boog900  )
20:48:00 <selsta> w​oodser: and non-cross compiled binaries work?
20:48:03 <m-relay> <0​xfffc:monero.social> selsta if we check the hardfork, can we skip the validation?
20:51:07 <selsta> what's allowed in the txpool isn't necessarily hardfork related
20:51:25 <selsta> for example we plan to drop timelocked transactions soon without waiting for a hardfork
20:51:30 <selsta> with a large txpool it can take multiple minutes to start monerod so I thought about it before why it validates the txpool on startup but I don't think it can be removed
20:52:55 <m-relay> <0​xfffc:monero.social> I see, thanks . in anycase, even if we are required to do `validation` , we still doing `O(n^2)` for an operation that we should only do `O(n)` . so that `O(n^2)` can be optimized.
20:55:36 <selsta> if it can be optimized then that would be nice
20:55:42 <selsta> jeffro256: please open https://github.com/monero-project/monero/pull/9343 against release branch
20:59:09 <m-relay> <r​ucknium:monero.social> You could also check if the node broadcasts the stale txpool to peers after startup. Some analysis of p2p logs suggests that it does.
21:01:49 <m-relay> <b​oog900:monero.social> We could separate the relay checks, call them on startup and only do full verification if the hardfork changes?
21:03:17 <m-relay> <w​oodser:monero.social> selsta I'm seeing the same result with make release-static from 22.04, where the binaries are incompatible
21:04:59 <selsta> that's really weird, what hardware does the 20.04 and 22.04 device have?
21:07:40 <m-relay> <w​oodser:monero.social> they are parallels desktop vms running on mac m3
21:08:34 <m-relay> <w​oodser:monero.social> this only applies for arm64
21:17:14 <m-relay> <v​tnerd:monero.social> 0xfffc: are you going to try and patch the n^2 code?
21:17:42 <m-relay> <0​xfffc:monero.social> vtnerd:  yes, I am looking into this.
21:17:50 <m-relay> <0​xfffc:monero.social> let me know if you have any feedback on this. thanks.
21:19:13 <selsta> w​oodser: both are on the m3 mac and both are arm64 / armv8 ubuntu VMs? (20.04 and 22.04)?
21:21:02 <m-relay> <w​oodser:monero.social> yes
21:23:25 <selsta> can you update the issue since it's not depends related
21:24:41 <m-relay> <w​oodser:monero.social> selsta yes sure, just udpated
22:43:49 <m-relay> <p​reland:monero.social> From my experience, make depends is a nightmare to work with unless you are using the exact runner that the GitHub workflow uses
22:43:50 <m-relay> <p​reland:monero.social> And I do mean *exact*; even a fresh chroot of ubuntu 20.04 errored out for me
22:43:52 <m-relay> <p​reland:monero.social> Albeit I was using make depends to cross-compile for Mac, so it was going to be an uphill battle from the start
22:43:54 <m-relay> <p​reland:monero.social> (For those who want to cross-compile, I have only been able to get it working locally on Debian bookworm; verified on both a chroot and in a Qube)