.merges

Wednesday

k

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

== 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?

mx7[m]: did you consider reorgs? there is unlikely a 64 block deep reorg

but I don't know, hyc or sech1 can explain

Ok thx, pinging hyc and sech1 ^

are monero-project/monero #6810 and monero-project/monero #7412 only in master or also in the latest release?

I think only master

ok

a clarification on monero-project/monero #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

firmware version is not the same as app version

yeah, got confused because they were almost the same version. thanks selsta

.merge+ 7773

Added

.merge+ 7906

...

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:

And for the release branch:

Other UB branches of mine have not much more complexity than these two and could save a lot of irritation for the Users.

Here's a filter for the UB branches:

Can you speed up reproduction of failure to few minutes at least ? I want to check under debugger what is going on there

wfaressuissia[m]: this should get you going.

2 minutes on my machine.

mj-xmr you could just call WalletImpl::pauseRefresh(); instead of renaming methods

"pauseRefresh();" -> "WalletImpl::pauseRefresh();"

then 7867 would be one-liner

hmmm this makes sense.

20 minutes gone, not reproduced with debug build

It's called Undefined Behavior for a reason.

"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

I'm not sure if you read correctly - I said it occurs in 10% of cases.

and not necessarily in Debug mode.

36 runs with release build and no error

cmake -S . -B build -D ARCH="default" -D BUILD_TESTS=ON -D CMAKE_BUILD_TYPE=release

This is what the CI uses, where the bug reoccurs.

bad that there is no docker with equivalent environment to github actions

I'm recompiling with gcc now, previous try was with clang

not reliable reproduction, not even 10% :(

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 github.com/plowsof/xmr-wishlist-aaS/blob/main/README.md

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 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 github.com/plowsof/xmr-wishlist-aaS

gcc build, 65 runs, no error

<wfaressuissia[m]> "not reliable reproduction, not..." <- Damn computers.

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. ...".

" 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.

if there is any good test to see problems in reality without those UB patches, then let me now.

98 runs, no error

I'm going to stop now.

<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.

Can you wrap it into docker ?

I know you can, please, do :)

Maybe later.

wrap, check locally that it reproduces the error and share dockerfile

Also problem with virtual methods should appear deterministically. But in this case it isn't true, so we need real source of problem there.

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

I'm also not really sure how to go about moving forward on this

changes are not too exciting so that kinda fuels lethargy in proceeding

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.

<karce[m]> "Any Monero projects out there..." <- Maybe check at #monero-rs on libera.chat

karce[m]: #monero-swap is all rust

that said we could branch next week if we want

Is the fee PR being postponed?

no

UkoeHB: or why do you ask?

> that said we could branch next week if we want

The PR doesn't seem to be 1 week away.

BP+ also has to bereviewed

so yea, 1 week won't happen

<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.

Rucknium[m]: this is probably best to punt imo

just because who knows what will happen there

"This" meaning mixin selection algorithm?

we need reviews of both BP+ and the fee implementation? I thought BP+ was reviewed already

yeah punt the algo change

punt, bump, idk what people use. but to not include as a blocker for this upgrade

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.

ok so we'll branch next week

(jk)

pls tho ;p

karce[m]: the btc-xmr atomic swap project is in rust: github.com/farcaster-project we hang out at #monero-swap

Ok thanks zkao I'll come over there where the cool kids hang out.

<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: github.com/comit-network/xmr-btc-swap/issues and doing our best to address them.