tusko: wtf are you talking about?\

<tusko> "Probably the underlying randomx..." <- What gives you that idea?

hyc, gonbatfire[m], What makes you think that it hasn't? If not randomx then some other moving piece. That is, if you believe Monero is a viable threat to the types of people who would work such into a piece of software, wouldn't it be your base assumption that they'd attempt to attack the codebase?

nobody has attacked the randomx codebase. it's too small, it's been audited 4 times.

look at the git logs, nothing significant has changed in the commits

hyc, ok, that's fine. it wasn't meant to be a personal attack. But I do expect that Monero's codebase may have been targeted by very not chill people

that may be. but you can ask anyone who's submitted a PR lately. they all get nitpicked to death.

nobody is sneaking anything thru

we're not novices. we know the games. put in an obvious flaw to draw reviewers' attention, to cover for some other more insidious attack. all that nonsense.

none of it will get by.

Sure, those can be detected. But what about a flaw in the cryptosystem, something violating Kerckhoffs's desideratum?

No offense, but even very brilliant people can make mistakes in this area that are notoriously difficult to detect.

"the cryptosystem" ? since we're using primitives that are common to crptography systems everywhere, that would imply a more serious vuln that affects more than just monero

I doubt anyone would object to you auditing the codebase, if that’s what you want to do. The more eyes the better

hyc, What are the primitives for randomx exactly? You make it sound like they are, idk, something very common

I'm certainly less knowledgeable than you are here

blake2b, aes, etc...

argon

oh, interesting. did not know. does the aes implementation use a lookup table?

it will use hardware AES if available.

which is why I discourage people from using Pis and other systems that don't provide hardware AES

oh, that's very good. I'm assuming that means NI-AES

yes

anyway, all of this stuff has been around a long time, heavily studied, cryptanalyzed, etc.

So then 'randomz'

oops

'randomx' must refer to a cryptosystem that uses these primitives to encode/decode meassages, no?

nope

they scramble data

whether it can be decoded again is irrelevant.

right, because you're using these random strings as random programs for the POW?

yes

But then why go through so much trouble rather than just pack any sufficiently random data into the program?

"sufficiently random" by what measure?

we know for a fact that the output of our PRNG is unpredictable, because it uses crypto primitives whose output is unpredictable

if they were predictable, they would be really shitty crypto ciphers...

Sure, I just wonder if you could not harvest enough entropy to satisfy some criterion locally from clock drift, temperatures, etc.

you n't measure clock drift accurately enough to yield enough bits

can't*

you can't even measure temperature on a lot of systems

the approach taken here is optimal for the broadest cross section of compute devices

I seem to recall reading some NIST proclamation recently that suggested clock drift was feasible, but I'm happy to accept that it is not

the NTP is in version 4 now over many decades. measuring clock drift is extremely difficult.

btw, my company is part of the Network time Foundation too. we know this shit.

you can't even do it within a single machine. you need long-duration communication with multiple peers to have a chance.

<moneromooo> "OK, I found your nick in the..." <- Yeah, sorry for the lack of context.... (full message at <libera.ems.host/_matrix/media/v3/do…a704db97ffe439d8cb3abb91fe3af469810>)

Well, I usually suggest using the software, finding something that's broken or rough, and improving it. That gives you a (typically) easy entry to a (usually) small amount of work with a clear goal and a tangible benefit at the end.

As for PoW, it's a complex piece of code, but it *is* low level. Further optimizing the JIT would be nice, but it's been looked at a lot already so further speedups are going to be hard work.

Maybe ARM is easier to improve, since I expect most work was spent on the x86_64 version. I've not followed though.

Review's always good. Maybe following the code to make sure secret info is wiped after use.

secret_key is automatically wiped, but rct::key isn't, since it's a catch-all type, so some might be missing.

Maybe checking net code for easy wins performance wise.

The code that decides what to download from where when syncing the chain is very ad hoc and probably far from optimal.

That's probably a thorny one though.

And what do you think about the refresh concurrency considering what I said?

Wallet ? I think it's not too difficulty and fairly well contained. If you have a more precise question, ask.

To be clear, I'm refering to the code that fetches blocks while processing blocks it has already fetched.

That's two main threads (processing it also locally threaded at particular places).

This particular arrangement is where I think fairly easy wins can be made.

Actually, AFAIK there's a whole new wallet being written, so maybe ask ukoehb about this, whether they have low level stuff there needing work.

Yeah I also started thinking about this new wallet. If it will eventually replace the existing implementation...

I'll ping him to see.

I'm seeing that a multisig wallet can no longer sign and publish txs from its peers after creating an unrelayed, unsigned tx, due to error message `This signature was made with stale data: export fresh multisig data, which other participants must then use`. is this expected? I'd think creating an unrelayed tx locally shouldn't make the multisig stale

It might be reusing the same outputs. Check this. If so, and you can't get a new ms state, you can freeze those outs temporarily to force using new outputs.

Reusing ms... values... k IIRC ? is dangerous.

darn in our use case, it would be the same output

I guess you could change the wallet to create more than one set of values per output. Defaulting to 1.

Then you could reuse the same output.

Not sure it's worth the added complexity though.

Depends if that use case is generally useful :)

I have it working now by sending updated multisig hex along with messages which need to be sent anyway, which is good because I really wanted to avoid that extra hop. the use case is useful I think but time will tell :)

hello

how to find why monerod crash on xiaomi aarch64 because termux crash with monerod and i cant log on gdb

crash happens when i start mining

I'm testing

Guest28: You need to take your questions to Monero support. This is Monero development.

he has a callstack paste.debian.net/1259123 so it's kind of -dev too

that stack is without mining

this is when i start mining

<hyc> "which is why I discourage people..." <- henlo, any idea if aes implemented on riscv? like, in monero/CMakeLists.txt it says `message(STATUS "AES support not available on RISC-V")` but there seems to have been some work done for aes over github.com/riscv/riscv-crypto

for just $79, the visionfive v2 has 8gb lpddr4, a u74 quadcore rv64gc, if aes working on it, that could such a nice piece of hardware for a potential node or somethin o.o

nobody has written JIT for risc-v yet

perhaps it'd be a good project for you. you can start just by copying the existing x86-64 or aarch64 code and tweaking incrementally

am dumbdumb but good to know, thanks for the info :3

Hello. How is the nonce added to the `blockhashing_blob` data from get_block_template before hashing it with Randomx?

Is it just appended to the end of the blockhashing_blob?

And how long is the nonce? 8 bytes?

Usually 4 bytes IIRC.

Well, the pool one.

The block one is also 4 bytes.

Then you can twiddle the timestamp too.

moneromooo: really it's just 4 bytes?

Let me go check now

It is.

It's not appended, it's somewhere in the middle. End of the header. The tx merkle tree comes after it.

Since the timestamp is in seconds, doesn't that mean that bad things might happen if the nethash is more than 4294967296 H/s = 4.294 GH/s

If your miner can only change those, I guess.

And if *your* hash is that much.

(assuming your math is right, I'm not checking)

If your hash rate is that high, just twiddle something else or let someone else have a chance :P

Wait what? Why would the timestamp be bad for pow?

moneromooo: so if i have a blockhashing_blob like this:

`0e0ed286da8006ecdc1aab3033cf1716c52f13f9d8ae0051615a2453643de94643b550d543becd00000000d130d22cf308b308498bbc16e2e955e7dbd691e6a8fab805f98ad82e6faa8bcc06` where is the nonce placed?

Timestamp is timestamp, miners work on nonce

Dunno. I'm not decoding this for you.

merope: but if timestamp changes, blockhashing_block changes too, right?

so you can re-use a previously-used nonce

Oh. I see.

Sure

Nonce is a misnomer here, you can have the same nonce for multiple blocks.

If you run out of nonces before the next second, you start changing stuff in the tx_extra field in the miner transaction

anyway i found answer to my question monero.stackexchange.com/questions/…et-some-guidance-please/10832#10832

Also referred to as "extra_nonce"

oh ok

That's how btc does it too, where the hashrate of any individual miner is way higher than that by several orders of magnitude

Note: this issue only arises when the individual mining device goes through the 2^32 nonce space in less than 1 second

Not the global network hashrate

(Assuming that pools don't reuse the exact same template for multiple miners)

on behalf of duggavo 'thank you for helping me, i appreciate your input'

thank you for helping me, i appreciate your input

nonce is at bytes 39-42 in the hashing blob

extra_nonce can be changed, but you'll have to call get_block_template again if you want another value of extra_nonce

<sech1> "nonce is at bytes 39-42 in the..." <- Thank you

reminder to update if you compile monero with openssl 3 openssl.org/blog/blog/2022/11/01/email-address-overflows

Thanks

> Q: Is this a branded vulnerability?

Does monero actually use X.509 certs?

yes for RPC SSL

<selsta> "reminder to update if you..." <- @selsta does this include things like monerujo using openssl 3.0.6 in the cmake etc?

the issue is more relevant for someone potentially remotely crashing a daemon

i don't know how relevant this issue is for monero or if it is even exploitable, worst case your wallet would crash if you connect to a malicious remote node