02:05:59 <selsta> .merges
02:05:59 -xmr-pr- 7342 7616 7823 7828 7855 7858 7875 7880 7883 7884 7898 7899
03:32:19 <luigi1111> Wednesday
03:38:13 <selsta> k
03:43:21 <mx7[m]> Hello. Have a question about RandomX. Why isn't the key change every block, say using previous block hash or some other data from previous block?  RandomX doc says "the key should change every 2048 blocks (~2.8 days) and there should be a delay of 64 blocks (~2 hours) between the key block and the change of the key K. This can be achieved by changing the key when blockHeight % 2048 == 64 and selecting key block such that keyBlockHeight % 2048
03:43:21 <mx7[m]> == 0" but there is no detail of any security assumptions and why 2048 and a delay of 64 blocks is ideal. Maybe there was a discussion about this somewhere?
04:05:58 <selsta> mx7[m]: did you consider reorgs? there is unlikely a 64 block deep reorg
04:06:06 <selsta> but I don't know, hyc or sech1 can explain
04:10:14 <mx7[m]> Ok thx, pinging hyc  and sech1 ^
08:30:25 <ErCiccione> are https://github.com/monero-project/monero/pull/6810 and https://github.com/monero-project/monero/pull/7412 only in master or also in the latest release?
08:33:33 <selsta> I think only master
08:34:19 <ErCiccione> ok
08:38:25 <ErCiccione> a clarification on https://github.com/monero-project/monero/pull/7789/. Is the ledger minimum version 1.7.6 now (changed from 1.6.0)? We say min firmware version for ledger nano s is 1.6.1 on getmonero
08:42:41 <selsta> firmware version is not the same as app version
08:47:15 <ErCiccione> yeah, got confused because they were almost the same version. thanks selsta
09:44:32 <selsta> .merge+ 7773
09:44:32 <xmr-pr> Added
09:44:49 <selsta> .merge+ 7906
09:44:49 <xmr-pr> ...
11:23:25 <mj-xmr[m]> I'm running local tests of the random mining test crash since yesterday. It occurred in about 10% of cases on two series of tests. Similarly on Github. I applied the PR 7867 and still no crashes after 30 tries. Therefore I'd ask for a reviewer for this PR, if you're looking for something that stabilizes the CI:
11:23:28 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7867
11:23:40 <mj-xmr[m]> And for the release branch:
11:23:47 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7868
11:25:21 <mj-xmr[m]> Other UB branches of mine have not much more complexity than these two and could save a lot of irritation for the Users.
11:26:22 <mj-xmr[m]> Here's a filter for the UB branches:
11:26:23 <mj-xmr[m]> https://github.com/monero-project/monero/pulls?q=is%3Aopen+is%3Apr+author%3Amj-xmr+UB
11:39:38 <wfaressuissia> Can you speed up reproduction of failure to few minutes at least ? I want to check under debugger what is going on there
11:41:56 <mj-xmr[m]> https://paste.debian.net/1210749/
11:43:11 <mj-xmr[m]> https://paste.debian.net/1210750/
11:43:37 <mj-xmr[m]> wfaressuissia[m]: this should get you going.
11:43:59 <mj-xmr[m]> 2 minutes on my machine.
11:57:12 <sech1> mj-xmr you could just call WalletImpl::pauseRefresh(); instead of renaming methods
11:57:34 <sech1> "pauseRefresh();" -> "WalletImpl::pauseRefresh();"
11:58:41 <sech1> then 7867 would be one-liner
11:58:44 <mj-xmr[m]> hmmm this makes sense.
12:05:50 <wfaressuissia> 20 minutes gone, not reproduced with debug build
12:08:53 <mj-xmr[m]> It's called Undefined Behavior for a reason.
12:11:14 <wfaressuissia> "Can you speed up reproduction of failure to few minutes at least ? ..." thanks for suggestion, but it doesn't allow to reproduce it within few minutes
12:11:50 <mj-xmr[m]> I'm not sure if you read correctly - I said it occurs in 10% of cases.
12:12:05 <mj-xmr[m]> and not necessarily in Debug mode.
12:30:51 <wfaressuissia> 36 runs with release build and no error
12:37:05 <mj-xmr[m]> cmake -S . -B build -D ARCH="default" -D BUILD_TESTS=ON -D CMAKE_BUILD_TYPE=release
12:37:23 <mj-xmr[m]> This is what the CI uses, where the bug reoccurs.
12:38:10 <wfaressuissia> bad that there is no docker with equivalent environment to github actions
12:38:14 <wfaressuissia> I'm recompiling with gcc now, previous try was with clang
12:48:20 <wfaressuissia> not reliable reproduction, not even 10% :(
13:13:54 <plowsof[m]> If any of you would like to have a 'wishlist' on your freely hosted github page (think 'your own ccs') take a look at this. Hopefully its of use to some here https://github.com/plowsof/xmr-wishlist-aaS/blob/main/README.md
13:14:36 <plowsof[m]> s/If any of you would like to have a 'wishlist' on your freely hosted github page (think 'your own ccs') take a look at this. Hopefully its of use to some here https://github.com/plowsof/xmr-wishlist-aaS/blob/main/README.md/If any of you would like to have a 'wishlist' on your freely hosted github page (think 'your own ccs') take a look at this. Hopefully its of use to some here https://github.com/plowsof/xmr-wishlist-aaS/
13:20:16 <wfaressuissia> gcc build, 65 runs, no error
14:38:48 <mj-xmr[m]> <wfaressuissia[m]> "not reliable reproduction, not..." <- Damn computers.
14:53:18 <wfaressuissia> It's expected that all those UB patches are at most protection against further changes of code. Without reproduction stop_mining() failure I can't event test this  claim " applied the PR 7867 and still no crashes after 30 tries. ...". 
14:54:00 <wfaressuissia> "    https://eel.is/c++draft/class.cdtor#4" it's good example of problems with virtual methods in constructor, but in our case there is no such complex hierarchy. 
14:54:45 <wfaressuissia> if there is any good test to see problems in reality without those UB patches, then let me now.
14:55:10 <wfaressuissia> 98 runs, no error
14:55:18 <wfaressuissia> I'm going to stop now.
15:08:14 <mj-xmr[m]> <wfaressuissia[m]> "if there is any good test to see..." <- It seems, that your machine is a poor way of reproducing what happens on Github CI, unlike mine. We typically run our forks' master periodically on GH to reproduce GH problems.
15:09:02 <wfaressuissia> Can you wrap it into docker ? 
15:09:15 <wfaressuissia> I know you can, please, do :)
15:09:31 <mj-xmr[m]> Maybe later.
15:09:38 <wfaressuissia> wrap, check locally that it reproduces the error and share dockerfile
15:20:46 <wfaressuissia> Also problem with virtual methods should appear deterministically. But in this case it isn't true, so we need real source of problem there.
21:10:36 <sgp_[m]> What is the status of the next upgrade timeline? It seems we have circled a late November release, but afaik, nothing has been committed to
21:10:56 <sgp_[m]> I'm also not really sure how to go about moving forward on this
21:24:48 <luigi1111> changes are not too exciting so that kinda fuels lethargy in proceeding 
21:44:14 <karce[m]> Any Monero projects out there that need a Rust/Python developer? Don't know C++, or really have any interest in re-learning it, but wanted to offer just in case there were some Monero/Rust related projects that want some love.
21:53:12 <nikg83[m]> <karce[m]> "Any Monero projects out there..." <- Maybe check at #monero-rs on libera.chat
21:57:48 <selsta> karce[m]: #monero-swap is all rust
22:26:28 <luigi1111> that said we could branch next week if we want
22:29:19 <UkoeHB> Is the fee PR being postponed?
22:29:39 <selsta> no
22:34:39 <selsta> UkoeHB: or why do you ask?
22:35:06 <UkoeHB> > that said we could branch next week if we want
22:35:06 <UkoeHB> The PR doesn't seem to be 1 week away.
22:35:26 <selsta> BP+ also has to bereviewed
22:35:38 <selsta> so yea, 1 week won't happen
22:38:29 <Rucknium[m]> <sgp_[m]> "What is the status of the next..." <- I think jberman and I would be able to produce a more thoroughly-vetted medium-term overhaul of the mixin selection algorithm if a hardfork was later than late November. The medium-term solution doesn't necessarily have to be included in the hardfork, though, since it is not a consensus item. Including it with the hardfork would help ensure transaction uniformity, though.
22:40:58 <sgp_[m]> Rucknium[m]: this is probably best to punt imo
22:41:05 <sgp_[m]> just because who knows what will happen there
22:41:39 <Rucknium[m]> "This" meaning mixin selection algorithm?
22:41:40 <sgp_[m]> we need reviews of both BP+ and the fee implementation? I thought BP+ was reviewed already
22:41:48 <sgp_[m]> yeah punt the algo change
22:42:36 <sgp_[m]> punt, bump, idk what people use. but to not include as a blocker for this upgrade
22:45:44 <Rucknium[m]> sgp_:  I think punting would be OK. It may be good to wait a week or so to make a final GO/NO GO call on it, after luigi1111 and moneromoooo review some work of myself and jberman.
22:52:27 <luigi1111> ok so we'll branch next week 
22:52:41 <luigi1111> (jk)
22:53:47 <sgp_> pls tho ;p
23:13:57 <zkao> karce[m]: the btc-xmr atomic swap project is in rust: https://github.com/farcaster-project/ we hang out at #monero-swap
23:14:43 <karce[m]> Ok thanks zkao I'll come over there where the cool kids hang out.
23:33:29 <Rishab[m]> <karce[m]> "Any Monero projects out there..." <- We have a xmr-btc atomic swap project in rust :) There is also bitcoin and libp2p involved. We are currently overloaded with user created issues and feature requests: https://github.com/comit-network/xmr-btc-swap/issues and doing our best to address them.