<s​trawberry:monero.social> According to this, XMRig uses a fixed offset for where the nonce is meant to be in the hashing blob: github.com/xmrig/xmrig/blob/7897f10…1/src/base/net/stratum/Job.cpp#L174

<s​trawberry:monero.social> Since the nonce comes after the timestamp, which is a varint, isn't this dangerous? Once timestamp varints eventually become 6 bytes long, this offset will be wrong and from what I understand, that means miners will start replacing the last byte of the prev block hash thinking it's part of the nonce, making them mine invalid blocks

Yes

Reminder: fix it in XMRig before Tue Oct 26 3058 03:46:08 GMT+0000

I have just a bit more than 1000 years to fix it :D

<s​trawberry:monero.social> Major and minor version are also varints, there's more chance one of those will become 2 bytes before 3058

All pool software also uses fixed nonce offset. I think it's a bit early to talk about the fix, because many things can change before Monero v128 :)

P2Pool software calculates nonce offset correctly, thanks to parsed block template handily available

<p​reland:monero.social> Let’s just make sure that the fixed nonce doesn’t become *too* embedded into the currency infrastructure

<p​reland:monero.social> The people using XMR 1000 years in the future will thank us lol

<p​reland:monero.social> (Ie we don’t need to fix it per se, we just need to keep it fix*able*)

Everyone will use P2Pool in 1000 years :D

<p​reland:monero.social> The good ending:)

<j​0j0xmr:monero.social> Is there an ETA on v0.18.3.4?

<f​ede:xmr.mx> is there an ETA on RandomX v2?

<s​yntheticbird:monero.social> tomorrow morning

<f​ede:xmr.mx> also FCMP, i haven't heard any updates for a while

<o​frnxmr:monero.social> Its progressing, i think you'll probably find more info in monero-research-lab or monero-research-lounge

<j​0j0xmr:monero.social> Is this really happening? Will it require a hard fork?