01:47:36 <moneromooo> hyc: in rx_slow_hash, the first parameter is mainheight. It's the height of the main chain. Should it not be the height of the block we want to calculate the hash for ?
01:48:22 <moneromooo> It's used to calc the seed height, so it'd make sense to me.
01:49:32 <moneromooo> I have a feeling we already went through that. It doesn't make sense on the face of it, but I think I was already told why...
01:49:57 <moneromooo> Logically, the height of the main chain is irrelevant if you calc the hash of a given block...
02:14:27 <moneromooo> Damnit, *something* feels fishy in there.
06:29:06 <sech1> moneromooo mainheight is for the main chain height because the first comment there says "if alt block but with same seed as mainchain, no need for alt cache"
06:29:22 <sech1> so it needs mainheight to know if the seed hash is the same or not
06:29:52 <sech1> I think :D
08:29:44 <rbrunner> I am using this C# code which more or less seems to be "the" Curve25519 implementation for C#: https://github.com/hanswolff/curve25519
08:30:18 <rbrunner> If I use this to derive public keys from private keys I get completely different keys from Monero. Any idea why?
08:30:48 <rbrunner> (I guess this happens when a complete crypto noob tries this stuff.)
08:50:24 <rbrunner> And just for fun, a Python library for Curve25519 gives yet another third result, different from both Monero and the C# library: https://pypi.org/project/PyNaCl/
09:03:23 <rbrunner> Example: Private key: 0b557492abbfb752edbec0a03a834d3fb99f8b6ed1056ad6920fd49c73258a68
09:03:37 <rbrunner> Public key, Monero: 11d09bfdb975ba94d5d5169fa931c9f791f4a0579bb66e6e99a478724ae70443
09:04:02 <rbrunner> Puplic key, Python: 58924f7c36f1526708920d0a989516f2ff5fa0f670c8e99cc9ea03ebfcee4541
09:04:42 <rbrunner> Public key, C#: 9fc157123c4165ec5df9996ab2508b10fbe76757b39beac9e7910422447ab632
09:56:45 <rbrunner> Manually translating the whole Monero C++ crypto stuff to C# almost looks like the easiest way out, but after all I would very much like to understand the differences and where I went wrong (if its my wrong)
10:35:41 <moneromooo> https://paste.debian.net/hidden/bf72f70d/
10:36:23 <moneromooo> That patches shows rx_slow_hash getting back different values when called with different mainheight. It applies on top of PR 6660.
10:36:55 <moneromooo> Run with: ./tests/functional_tests/functional_tests_rpc.py /usr/bin/python tests/functional_tests build/Linux/mining/release p2p
10:38:31 <moneromooo> It will die at some point. In build/Linux/mining/release/tests/functional_tests/monero2.log, there'll be a message: Block with id ... does not have enough proof of work.
10:39:07 <moneromooo> Then grep the block hash in build/Linux/mining/release/tests/functional_tests/monero[23].log, it will show rx_slow_hash returning two different hashes, and the parameters it was called with.
10:39:23 <moneromooo> Apologies in advance if I'm doing something dumb ^_^
10:55:32 <moneromooo> This also needs PR 6111. And the test overrides the randomx epoch blocks to 8 and lag to 4, so we get to exercise this a lot.
10:55:50 <moneromooo> I believe this is valid, but maybe this is out of valid bounds ?
14:25:51 <hyc> moneromooo: yes, we've had this conversation before. we calc the seedhash of the mainchain to see if we can continue to use the cached randomx state
14:26:06 <hyc> seedheight
14:26:58 <moneromooo> OK. Mind checking the patch to see whether I'm doing something wrong ?
14:29:51 <hyc> so I just need PR 6111 and the paste?
14:30:43 <moneromooo> 6111 + 6660 + paste
14:37:39 <hyc> compiling now...
14:37:49 <hyc> hm, wait I didn't change the epoch
14:38:06 <moneromooo> The test change the epoch automatically.
14:38:54 <hyc> oh ok
14:39:08 <hyc> and yes sech1's reply was correct
14:41:05 <hyc> moneromooo: why "!!seedhash" ?
14:42:52 <moneromooo> seed hash is passed when called from RPC IIRC, this is likely an old block. Not passed when called from blockchain.cpp.
14:47:10 <hyc> what is PR#6111 about? fix mining from a block that's not the current top - how can you mine from a block that's not the current top?
14:48:19 <moneromooo> Well, the same as for the top block. You just build a block template from that block.
14:49:39 <hyc> but it's not valid to mine from any other block
14:50:09 <moneromooo> Oh. That kinda explains the bad hashes then...
14:50:11 <moneromooo> Why ?
14:50:31 <hyc> I mean, unless you're trying to intentionally create a chain fork
14:50:38 <moneromooo> I am.
14:51:57 <hyc> I don't see how that can work within 1 daemon
14:51:58 <moneromooo> By invalid, you mean "it's not supposed to work with randomx" or just "it will fork" ?
14:52:35 <hyc> especially with the tiny epoch size here
14:52:59 <hyc> if you mine past the epoch, then one or the other fork will be using invalid seedhashes
14:53:12 <moneromooo> Well, that's my problem :)
14:54:02 <moneromooo> I mean, if you specifically decided "we're not going to allow this when mining with randomx", then it's a bit unfortnuate, but fair enough I guess.
14:54:15 <hyc> if you want to test a chainfork you need two separate daemons, two separate blockchain DBs
14:54:30 <moneromooo> The last test does that.
14:54:33 <hyc> because each fork has to see its own seedhashes, which are looked up from the chain
14:55:51 <moneromooo> I mine from a block on the mainchain IIRC.
14:56:21 <hyc> well, if you mine more than epoch blocks, you're no longer referencing the mainchain
14:57:13 <moneromooo> I don't understand that.
14:57:30 <hyc> the seedhash comes from the previous epoch
14:57:43 <hyc> so once you've mined more than <epoch> blocks, you're into a new seedhash
14:57:50 <hyc> which has to come from your fork
14:59:12 <moneromooo> Are you saying that if someone creates a fork more than 2k ago, we're fucked because nobody will be able to sync it if they've gone into another branch ?
14:59:49 <moneromooo> (assuming it gets higher cumulative diff)
14:59:56 <hyc> no...
15:00:00 <hyc> syncing will work
15:00:11 <moneromooo> Good. Then why is this any different ?
15:00:14 <hyc> mining won't
15:00:20 <moneromooo> Why.
15:00:36 <moneromooo> You can get PoW from old blocks from the RPC. This is the same, no ?
15:00:48 <hyc> because the syncing code knows that it's looking at a chain of alt blocks
15:00:57 <hyc> and it knows how to search the alt chain for a seedhash if it needs it
15:01:38 <moneromooo> OK. That's what my second daemon does.
15:01:50 <moneromooo> On the test that fails.
15:02:09 <moneromooo> Daemon1 mines lots, disconnceted, then reconncets to dameon2, which syncs.
15:02:53 <moneromooo> Amusingly, the test that mines from a old block works.
15:04:09 <hyc> blockchain.cpp:1751 is where we check for an alt seedhash
15:04:31 <moneromooo> Right. I recall that code, yes.
15:04:52 <hyc> so anyway - the miner doesn't have any of that
15:05:35 * moneromooo goes look
15:06:38 <moneromooo> https://github.com/monero-project/monero/pull/6111/files#diff-1279d7b0ddc432573cd2bd8c6e632c1f
15:06:53 <moneromooo> Maybe it's buggy though. Guess that'll be my next target to check.
15:06:54 <hyc> hmmm. ok so you have daemon2 with chain height X
15:07:11 <hyc> then you set daemon1 to mine from X-foo
15:07:17 <hyc> have you popped blocks on daemon1?
15:08:07 <moneromooo> There was a reorg, so this popped a bit.
15:09:34 <moneromooo> But all the blocks mined in this test are from the dameon's top block.
15:09:40 <hyc> ok
15:10:27 <moneromooo> Oh, I just thought of a possible reason: 20 blocks in parallel, that's > epoch.
15:10:46 <moneromooo> That's likely an acceptable constraint. I'll change to 32 and see.
15:10:50 <hyc> ok
15:10:57 <hyc> yeah that would certainly be a problem
15:18:18 <moneromooo> Wait. Even then, the log shows it's using the same seed hash for the two different results.
15:18:55 * moneromooo running the test with 32 epoch now
15:19:42 <moneromooo> It's passed now. I'll run again with more blocks.
15:20:45 <tevador> rbrunner: Curve25519 is only for ECDH (key agreement), not for signing - Monero uses the twisted variant of that curve (Ed25519), so that's probably why you are getting different public keys
15:22:24 <rbrunner> Thanks tevador, will try. So probably I simply took the wrong curve. Still strange that 2 Curve25519 implementations would not agree, regardless of what Monero does ...
15:22:33 <luigi1111w> yeah rbrunner you need to adapt an eddsa library most likely
15:22:38 <hyc> hm, is this for python2 or python3 ?
15:22:58 <rbrunner> I am not sure, I think I ran it whith Python2
15:23:10 <moneromooo> Should work with both. I'm running with python 2.
15:23:13 <hyc> oh sorry, my question was for moo
15:23:14 <hyc> ok
15:23:29 <hyc> I was missing the requests module, it's only installed here for python3
15:23:35 <rbrunner> Ok, sorry for the confusion.
15:23:48 <luigi1111w> which did you figure out your keccak problem?
15:24:03 <luigi1111w> -which
15:24:40 <rbrunner> Me? Yes, keccac was ok, I must have confused something. I can now go correctly from a private spend key to a private view key
15:25:02 <luigi1111w> great
15:25:52 <luigi1111w> looks like that github user has an eddsa library too
15:26:12 <luigi1111w> at least in my nomenclature
15:26:24 <luigi1111w> they always double-use ed25519 to mean everything
15:27:23 <rbrunner> You mean this one: https://github.com/hanswolff/ed25519
15:29:09 <sarang> ed25519, edd25519, and eddy25519?
15:29:16 * sarang shows himself out
15:32:37 <tevador> rbrunner: this is perhaps the reason why you got different results from the C# and python libs: https://github.com/hanswolff/curve25519/blob/master/Curve25519/Curve25519.cs#L112
15:32:44 <tevador> your private key is not clamped
15:35:10 <rbrunner> Stupid question: Is "clamping" and "reducing" the same or not? And does Monero "clamp" its private keys before deriving the public keys?
15:43:05 <hyc> moneromooo: I used epoch/lag 64/32, test passed. not sure if blockchain was big enough with these params.
15:43:19 <hyc> I'll try 32/16
15:43:45 <moneromooo> I'm running with 32/8 atm, and mining 10 x 1k blocks.
15:44:24 <moneromooo> Still, if you run with 8/4, you get logs showing you get different results for the same results *except* main height, which I find very suspicious. In partiuclar, same seed hash.
15:45:07 <hyc> probably because the mainchain hashes aren't mutexed
15:45:18 * moneromooo stabs
15:45:24 <moneromooo> That'd explain...
15:45:34 <hyc> no, they don't need to be, when everything is in the same epoch
15:46:04 <hyc> 32/8 failed here
15:47:39 <moneromooo> Thinking about it, you'd get Blockchain::longhash_worker use two different seed hashes every time a 20 block chunk straddles a randomx epoch, since they're not aligned.
15:47:56 <moneromooo> So even for epoch 2048 (or whatever it actually is).
15:48:07 <moneromooo> It just happens a lot less.
15:49:20 <hyc> the current code handles that, that's why the alt cache exists
15:49:30 <hyc> but your 20 block chunk straddled more than 2 epochs
15:49:34 <hyc> it couldn't handle that.
15:49:39 <moneromooo> Ah. OK. That makes sense now.
15:50:25 <moneromooo> Irritatingly brittle though.
15:50:49 <hyc> handling more would require another chunk of 256MB
15:51:04 <moneromooo> So you'd need epoch at least 39 to be sure. So... 64 ?
15:51:19 <hyc> which is pointless, since the real operating parameters will never hit that
15:52:24 <moneromooo> Well, one 256 MB buffer for the latest seed hash, the other for anything else.
15:52:37 <moneromooo> The anything else slot is supposed to switch all the time.
15:52:54 <hyc> yes, that's the alt cache. and it is mutexed
15:53:22 <moneromooo> So why isn't it used when a block in a 20-chunk needs an earlier seed hash ?
15:53:43 <hyc> it ought to be, already
15:53:47 <moneromooo> Sorry if I'm being extra inquisitive on this, it just feels fishy still :0
15:54:06 <moneromooo> So why would there be a need for a third one if the second one can get all the non-latest seeds ?
15:54:14 <hyc> good question
16:01:43 <hyc> test always fails early here with lag=8
16:04:57 <hyc> works with lag=16
16:05:48 <moneromooo> My test with 32/8 and 10k blocks seems to be syncing just fine so far.
16:06:33 <moneromooo> That's the setting you said failed.
16:07:22 <moneromooo> Wait, to change epoch, you do that in the test right ? functional_tests.py
16:07:42 <moneromooo> If you change the defualt constants in the C file, they;ll get overridden by the test.
16:09:08 <moneromooo> 10k block 32/8 test succeeded here.
16:18:58 <hyc> yes just editing the test script
16:19:18 <hyc> how many CPU cores do you have?
16:21:29 <moneromooo> Not sure. /proc/cpuinfo shows 2 CPU entries, each with "siblings: 2" and "cpu cores: 2". I never know what's pre-multiplied.
16:22:36 <hyc> then you don't really have parallelism beyond 2 or 4
16:22:46 <hyc> I have 8 cores here
16:23:00 <moneromooo> Right, so you get easier races.
16:23:05 <hyc> yep
16:23:42 <moneromooo> IIRC it can go to 400% CPU when it goes full threads, so must be 4 cores altogether.
16:24:50 <hyc> ok
16:25:58 <hyc> so it seems there's a hole here, I'm just not sure if it's legit or not
16:39:40 <hyc> why aren't you using get_altblock_longhash, instead of patching get_block_longhash?
16:41:48 <moneromooo> From where ?
16:41:58 <hyc> from anywhere
16:42:25 <hyc> I don't understand why you added multiple instances of code to retrieve the seedhash
16:42:34 <moneromooo> Then why have get_block_longhash if you can call get_altblock_longhash everywhere ?
16:42:48 * moneromooo goes look
16:43:14 <wizardsmoke> ^
16:44:43 <moneromooo> You mean the loop looking in alt blocks ? I see just one of these in the patch (which I wrote months ago so my memory's a bit hazy).
16:45:23 <hyc> you add seed params to create_block_template
16:45:36 <hyc> which you wouldn't need to do, if your miner is always mining from the top block
16:45:58 <moneromooo> It's not always mining from the top block. It is doing so in the test we were looking at, but others tests don't.
16:46:08 <hyc> which makes no sense
16:46:26 <wizardsmoke> moneromooo: should have commented it better :3
16:46:45 <moneromooo> Because of using randomx in particular ?
16:46:57 <moneromooo> ie, it would make sense with, eg, cryptonight ?
16:47:16 <moneromooo> Because I don't agree with "mining from an old block makes no sense" in general.
16:47:17 <hyc> well, cryptonight had no blockchain dependency
16:47:30 <moneromooo> Yes. That's why I ask this question.
16:47:47 <hyc> sorry but I don't see it as valid at all
16:47:51 <moneromooo> I do.
16:47:58 <hyc> miners add to the tip of the chain, that's their job
16:48:29 <hyc> mining from an old block means explicitly creating a fork. if you need to create a fork in test, you popblocks until the old block is the tip.
16:48:45 <moneromooo> If you *choose* to have that not work and not care, it's OK, but it's a decision, not an inherent "does not make sense".
16:49:13 <hyc> fine. that was the assumption going into writing this code.
16:49:32 <moneromooo> OK. Then I think I understand it all now. Thanks for the help.
16:51:14 <moneromooo> So I guess I need to remove those tests since they're not meant to pass. Oh well.
16:55:18 <wizardsmoke> hyc: hi. we should collab on something, fam
20:23:50 <selsta> luigi1111w: do you have time to do CLI merges this weekend? Would like to prepare the next point release soon.
20:24:58 <luigi1111w> today yes
20:25:52 <selsta> ty
22:05:20 <Minimons> Hello! Is there any text explaining the format for an XMR address?
22:05:20 <Minimons> This is what I know:
22:05:20 <Minimons>  1) It starts with '4' for standard addresses
22:05:20 <Minimons>  2) Starts with '8' for derived accounts
22:05:20 <Minimons>  3) 95 chars for standard addresses
22:05:20 <Minimons>  4) 106 chars for integrated addresses
22:05:22 <Minimons> Are there more rules? Did hear something about the 2. char too?
22:09:21 <selsta> See https://monerodocs.org and Zero To Monero 2
22:09:31 <selsta> monerodocs has a whole page about addresses
22:16:48 <Minimons> selsta: Thanks for that! :-)
23:14:53 <UkoeHB_> Minimons: https://xmr.llcoins.net
23:15:42 <needbrrrrrrr90> sorry in advance for the meme, it's too good https://usercontent.irccloud-cdn.com/file/HaxC2aqy/image0-6.jpg
23:56:56 <xmrpow> jtgrassie around?