02:09:34 <hyc> tusko: wtf are you talking about?\
02:30:01 <gonbatfire[m]> <tusko> "Probably the underlying randomx..." <- What gives you that idea?
02:36:40 <tusko> 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?
02:39:17 <hyc> nobody has attacked the randomx codebase. it's too small, it's been audited 4 times.
02:40:14 <hyc> look at the git logs, nothing significant has changed in the commits
02:41:44 <tusko> 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
02:43:27 <hyc> that may be. but you can ask anyone who's submitted a PR lately. they all get nitpicked to death.
02:43:39 <hyc> nobody is sneaking anything thru
02:44:51 <hyc> 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.
02:45:00 <hyc> none of it will get by.
02:47:49 <tusko> Sure, those can be detected. But what about a flaw in the cryptosystem, something violating Kerckhoffs's desideratum?
02:48:34 <tusko> No offense, but even very brilliant people can make mistakes in this area that are notoriously difficult to detect.
02:48:47 <hyc> "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
02:48:57 <UkoeHB> I doubt anyone would object to you auditing the codebase, if that’s what you want to do. The more eyes the better
02:50:45 <tusko> hyc, What are the primitives for randomx exactly? You make it sound like they are, idk, something very common
02:50:58 <tusko> I'm certainly less knowledgeable than you are here
02:51:01 <hyc> blake2b, aes, etc...
02:52:05 <hyc> argon
02:52:05 <tusko> oh, interesting. did not know. does the aes implementation use a lookup table?
02:52:29 <hyc> it will use hardware AES if available. 
02:52:46 <hyc> which is why I discourage people from using Pis and other systems that don't provide hardware AES
02:52:57 <tusko> oh, that's very good. I'm assuming that means NI-AES
02:53:06 <hyc> yes
02:53:43 <hyc> anyway, all of this stuff has been around a long time, heavily studied, cryptanalyzed, etc.
02:54:11 <tusko> So then 'randomz'
02:54:14 <tusko> oops
02:54:41 <tusko> 'randomx' must refer to a cryptosystem that uses these primitives to encode/decode meassages, no? 
02:54:51 <hyc> nope
02:55:02 <hyc> they scramble data
02:55:15 <hyc> whether it can be decoded again is irrelevant.
02:55:47 <tusko> right, because you're using these random strings as random programs for the POW?
02:55:52 <hyc> yes
02:57:02 <tusko> But then why go through so much trouble rather than just pack any sufficiently random data into the program?
02:57:19 <hyc> "sufficiently random" by what measure?
02:57:48 <hyc> we know for a fact that the output of our PRNG is unpredictable, because it uses crypto primitives whose output is unpredictable
02:58:03 <hyc> if they were predictable, they would be really shitty crypto ciphers...
02:58:56 <tusko> Sure, I just wonder if you could not harvest enough entropy to satisfy some criterion locally from clock drift, temperatures, etc. 
02:59:33 <hyc> you n't measure clock drift accurately enough to yield enough bits
02:59:38 <hyc> can't*
03:00:02 <hyc> you can't even measure temperature on a lot of systems
03:00:23 <hyc> the approach taken here is optimal for the broadest cross section of compute devices
03:00:57 <tusko> 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
03:01:30 <hyc> the NTP is in version 4 now over many decades. measuring clock drift is extremely difficult.
03:05:20 <hyc> btw, my company is part of the Network time Foundation too. we know this shit.
03:09:33 <hyc> you can't even do it within a single machine. you need long-duration communication with multiple peers to have a chance.
07:49:18 <font-deny[m]> <moneromooo> "OK, I found your nick in the..." <- Yeah, sorry for the lack of context.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3d26aa704db97ffe439d8cb3abb91fe3af469810>)
08:07:37 <moneromooo> 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.
08:32:59 <moneromooo> 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.
08:33:42 <moneromooo> Maybe ARM is easier to improve, since I expect most work was spent on the x86_64 version. I've not followed though.
08:35:48 <moneromooo> Review's always good. Maybe following the code to make sure secret info is wiped after use.
08:36:17 <moneromooo> secret_key is automatically wiped, but rct::key isn't, since it's a catch-all type, so some might be missing.
08:36:46 <moneromooo> Maybe checking net code for easy wins performance wise.
08:37:15 <moneromooo> The code that decides what to download from where when syncing the chain is very ad hoc and probably far from optimal.
08:37:28 <moneromooo> That's probably a thorny one though.
08:41:32 <font-deny[m]> And what do you think about the refresh concurrency considering what I said?
08:44:02 <moneromooo> Wallet ? I think it's not too difficulty and fairly well contained. If you have a more precise question, ask.
08:44:59 <moneromooo> To be clear, I'm refering to the code that fetches blocks while processing blocks it has already fetched.
08:45:25 <moneromooo> That's two main threads (processing it also locally threaded at particular places).
08:45:40 <moneromooo> This particular arrangement is where I think fairly easy wins can be made.
08:46:29 <moneromooo> 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.
08:51:28 <font-deny[m]> Yeah I also started thinking about this new wallet. If it will eventually replace the existing implementation...
08:53:58 <font-deny[m]> I'll ping him to see.
09:21:01 <woodser[m]> 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
09:35:46 <moneromooo> 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.
09:36:34 <moneromooo> Reusing ms... values... k IIRC ? is dangerous.
09:41:57 <woodser[m]> darn in our use case, it would be the same output
10:00:17 <moneromooo> I guess you could change the wallet to create more than one set of values per output. Defaulting to 1.
10:00:29 <moneromooo> Then you could reuse the same output.
10:00:42 <moneromooo> Not sure it's worth the added complexity though.
10:00:57 <moneromooo> Depends if that use case is generally useful :)
10:31:39 <woodser[m]> 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 :)
12:18:45 <Guest28> hello
12:19:11 <Guest28> how to find why monerod crash on xiaomi aarch64 because termux crash with monerod and i cant log on gdb
12:19:59 <Guest28> crash happens when i start mining
12:20:11 <Guest28> I'm testing
12:21:37 <one-horse-wagon[> Guest28: You need to take your questions to Monero support.  This is Monero development.
12:22:58 <sech1> he has a callstack http://paste.debian.net/1259123/ so it's kind of -dev too
12:24:28 <Guest2830> that stack is without mining
12:27:17 <Guest2830> http://paste.debian.net/1259142/
12:27:24 <Guest2830> this is when i start mining
12:44:31 <spacekitty420[m]> <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 https://github.com/riscv/riscv-crypto
12:50:28 <spacekitty420[m]> 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
14:34:35 <hyc> nobody has written JIT for risc-v yet
14:35:40 <hyc> 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
14:43:34 <spacekitty420[m]> am dumbdumb but good to know, thanks for the info :3
14:53:23 <duggavo[m]> Hello. How is the nonce added to the `blockhashing_blob` data from get_block_template before hashing it with Randomx?
14:53:23 <duggavo[m]> Is it just appended to the end of the blockhashing_blob?
14:53:23 <duggavo[m]> And how long is the nonce? 8 bytes?
14:54:51 <moneromooo> Usually 4 bytes IIRC.
14:55:05 <moneromooo> Well, the pool one.
14:55:21 <moneromooo> The block one is also 4 bytes.
14:55:34 <moneromooo> Then you can twiddle the timestamp too.
14:55:36 <duggavo[m]> moneromooo: really it's just 4 bytes?
14:55:55 <moneromooo> Let me go check now
14:56:10 <moneromooo> It is.
14:57:00 <moneromooo> It's not appended, it's somewhere in the middle. End of the header. The tx merkle tree comes after it.
14:57:05 <duggavo[m]> 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
14:57:38 <moneromooo> If your miner can only change those, I guess.
14:58:10 <moneromooo> And if *your* hash is that much.
14:58:32 <moneromooo> (assuming your math is right, I'm not checking)
14:58:52 <moneromooo> If your hash rate is that high, just twiddle something else or let someone else have a chance :P
14:59:17 <merope> Wait what? Why would the timestamp be bad for pow?
14:59:18 <duggavo[m]> moneromooo: so if i have a blockhashing_blob like this: 
14:59:18 <duggavo[m]> `0e0ed286da8006ecdc1aab3033cf1716c52f13f9d8ae0051615a2453643de94643b550d543becd00000000d130d22cf308b308498bbc16e2e955e7dbd691e6a8fab805f98ad82e6faa8bcc06` where is the nonce placed?
14:59:29 <merope> Timestamp is timestamp, miners work on nonce
14:59:32 <moneromooo> Dunno. I'm not decoding this for you.
14:59:47 <duggavo[m]> merope: but if timestamp changes, blockhashing_block changes too, right?
15:00:00 <duggavo[m]> so you can re-use a previously-used nonce
15:00:12 <moneromooo> Oh. I see.
15:00:13 <merope> Sure
15:00:24 <moneromooo> Nonce is a misnomer here, you can have the same nonce for multiple blocks.
15:00:48 <merope> If you run out of nonces before the next second, you start changing stuff in the tx_extra field in the miner transaction
15:01:00 <duggavo[m]> anyway i found answer to my question https://monero.stackexchange.com/questions/10830/im-trying-to-create-a-python-miner-can-i-get-some-guidance-please/10832#10832
15:01:00 <merope> Also referred to as "extra_nonce"
15:01:28 <duggavo[m]> oh ok
15:01:45 <merope> That's how btc does it too, where the hashrate of any individual miner is way higher than that by several orders of magnitude 
15:02:21 <merope> Note: this issue only arises when the individual mining device goes through the 2^32 nonce space in less than 1 second
15:02:35 <merope> Not the global network hashrate
15:03:18 <merope> (Assuming that pools don't reuse the exact same template for multiple miners)
15:06:26 <plowsof> on behalf of duggavo 'thank you for helping me, i appreciate your input' 
15:06:39 <duggavo[m]> thank you for helping me, i appreciate your input
15:11:06 <sech1> nonce is at bytes 39-42 in the hashing blob
15:11:40 <sech1> extra_nonce can be changed, but you'll have to call get_block_template again if you want another value of extra_nonce
15:16:31 <duggavo[m]> <sech1> "nonce is at bytes 39-42 in the..." <- Thank you
18:00:34 <selsta> reminder to update if you compile monero with openssl 3 https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/
18:51:45 <moneromooo> Thanks
18:57:11 <moneromooo> > Q: Is this a branded vulnerability?
18:57:16 * moneromooo weeps
19:26:19 <RavFX[m]> Does monero actually use X.509 certs?
19:34:30 <selsta> yes for RPC SSL
19:37:44 <ofrnxmr[m]> <selsta> "reminder to update if you..." <- @selsta does this include things like monerujo using openssl 3.0.6 in the cmake etc?
19:40:00 <selsta> the issue is more relevant for someone potentially remotely crashing a daemon
19:43:23 <selsta> 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
21:56:27 * brkcore I can't find any indicator applet to show IP connection. How difficult is it to create one? anyone can give me an idea what to start read?