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 ?

It's used to calc the seed height, so it'd make sense to me.

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

Logically, the height of the main chain is irrelevant if you calc the hash of a given block...

Damnit, *something* feels fishy in there.

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"

so it needs mainheight to know if the seed hash is the same or not

I think :D

I am using this C# code which more or less seems to be "the" Curve25519 implementation for C#: github.com/hanswolff/curve25519

If I use this to derive public keys from private keys I get completely different keys from Monero. Any idea why?

(I guess this happens when a complete crypto noob tries this stuff.)

And just for fun, a Python library for Curve25519 gives yet another third result, different from both Monero and the C# library: pypi.org/project/PyNaCl

Example: Private key: 0b557492abbfb752edbec0a03a834d3fb99f8b6ed1056ad6920fd49c73258a68

Public key, Monero: 11d09bfdb975ba94d5d5169fa931c9f791f4a0579bb66e6e99a478724ae70443

Puplic key, Python: 58924f7c36f1526708920d0a989516f2ff5fa0f670c8e99cc9ea03ebfcee4541

Public key, C#: 9fc157123c4165ec5df9996ab2508b10fbe76757b39beac9e7910422447ab632

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)

That patches shows rx_slow_hash getting back different values when called with different mainheight. It applies on top of PR 6660.

Run with: ./tests/functional_tests/functional_tests_rpc.py /usr/bin/python tests/functional_tests build/Linux/mining/release p2p

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.

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.

Apologies in advance if I'm doing something dumb ^_^

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.

I believe this is valid, but maybe this is out of valid bounds ?

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

seedheight

OK. Mind checking the patch to see whether I'm doing something wrong ?

so I just need PR 6111 and the paste?

6111 + 6660 + paste

compiling now...

hm, wait I didn't change the epoch

The test change the epoch automatically.

oh ok

and yes sech1's reply was correct

moneromooo: why "!!seedhash" ?

seed hash is passed when called from RPC IIRC, this is likely an old block. Not passed when called from blockchain.cpp.

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?

Well, the same as for the top block. You just build a block template from that block.

but it's not valid to mine from any other block

Oh. That kinda explains the bad hashes then...

Why ?

I mean, unless you're trying to intentionally create a chain fork

I am.

I don't see how that can work within 1 daemon

By invalid, you mean "it's not supposed to work with randomx" or just "it will fork" ?

especially with the tiny epoch size here

if you mine past the epoch, then one or the other fork will be using invalid seedhashes

Well, that's my problem :)

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.

if you want to test a chainfork you need two separate daemons, two separate blockchain DBs

The last test does that.

because each fork has to see its own seedhashes, which are looked up from the chain

I mine from a block on the mainchain IIRC.

well, if you mine more than epoch blocks, you're no longer referencing the mainchain

I don't understand that.

the seedhash comes from the previous epoch

so once you've mined more than <epoch> blocks, you're into a new seedhash

which has to come from your fork

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 ?

(assuming it gets higher cumulative diff)

no...

syncing will work

Good. Then why is this any different ?

mining won't

Why.

You can get PoW from old blocks from the RPC. This is the same, no ?

because the syncing code knows that it's looking at a chain of alt blocks

and it knows how to search the alt chain for a seedhash if it needs it

OK. That's what my second daemon does.

On the test that fails.

Daemon1 mines lots, disconnceted, then reconncets to dameon2, which syncs.

Amusingly, the test that mines from a old block works.

blockchain.cpp:1751 is where we check for an alt seedhash

Right. I recall that code, yes.

so anyway - the miner doesn't have any of that

Maybe it's buggy though. Guess that'll be my next target to check.

hmmm. ok so you have daemon2 with chain height X

then you set daemon1 to mine from X-foo

have you popped blocks on daemon1?

There was a reorg, so this popped a bit.

But all the blocks mined in this test are from the dameon's top block.

ok

Oh, I just thought of a possible reason: 20 blocks in parallel, that's > epoch.

That's likely an acceptable constraint. I'll change to 32 and see.

ok

yeah that would certainly be a problem

Wait. Even then, the log shows it's using the same seed hash for the two different results.

It's passed now. I'll run again with more blocks.

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

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

yeah rbrunner you need to adapt an eddsa library most likely

hm, is this for python2 or python3 ?

I am not sure, I think I ran it whith Python2

Should work with both. I'm running with python 2.

oh sorry, my question was for moo

ok

I was missing the requests module, it's only installed here for python3

Ok, sorry for the confusion.

which did you figure out your keccak problem?

-which

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

great

looks like that github user has an eddsa library too

at least in my nomenclature

they always double-use ed25519 to mean everything

You mean this one: github.com/hanswolff/ed25519

ed25519, edd25519, and eddy25519?

rbrunner: this is perhaps the reason why you got different results from the C# and python libs: github.com/hanswolff/curve25519/blo…aster/Curve25519/Curve25519.cs#L112

your private key is not clamped

Stupid question: Is "clamping" and "reducing" the same or not? And does Monero "clamp" its private keys before deriving the public keys?

moneromooo: I used epoch/lag 64/32, test passed. not sure if blockchain was big enough with these params.

I'll try 32/16

I'm running with 32/8 atm, and mining 10 x 1k blocks.

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.

probably because the mainchain hashes aren't mutexed

That'd explain...

no, they don't need to be, when everything is in the same epoch

32/8 failed here

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.

So even for epoch 2048 (or whatever it actually is).

It just happens a lot less.

the current code handles that, that's why the alt cache exists

but your 20 block chunk straddled more than 2 epochs

it couldn't handle that.

Ah. OK. That makes sense now.

Irritatingly brittle though.

handling more would require another chunk of 256MB

So you'd need epoch at least 39 to be sure. So... 64 ?

which is pointless, since the real operating parameters will never hit that

Well, one 256 MB buffer for the latest seed hash, the other for anything else.

The anything else slot is supposed to switch all the time.

yes, that's the alt cache. and it is mutexed

So why isn't it used when a block in a 20-chunk needs an earlier seed hash ?

it ought to be, already

Sorry if I'm being extra inquisitive on this, it just feels fishy still :0

So why would there be a need for a third one if the second one can get all the non-latest seeds ?

good question

test always fails early here with lag=8

works with lag=16

My test with 32/8 and 10k blocks seems to be syncing just fine so far.

That's the setting you said failed.

Wait, to change epoch, you do that in the test right ? functional_tests.py

If you change the defualt constants in the C file, they;ll get overridden by the test.

10k block 32/8 test succeeded here.

yes just editing the test script

how many CPU cores do you have?

Not sure. /proc/cpuinfo shows 2 CPU entries, each with "siblings: 2" and "cpu cores: 2". I never know what's pre-multiplied.

then you don't really have parallelism beyond 2 or 4

I have 8 cores here

Right, so you get easier races.

yep

IIRC it can go to 400% CPU when it goes full threads, so must be 4 cores altogether.

ok

so it seems there's a hole here, I'm just not sure if it's legit or not

why aren't you using get_altblock_longhash, instead of patching get_block_longhash?

From where ?

from anywhere

I don't understand why you added multiple instances of code to retrieve the seedhash

Then why have get_block_longhash if you can call get_altblock_longhash everywhere ?

^

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

you add seed params to create_block_template

which you wouldn't need to do, if your miner is always mining from the top block

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.

which makes no sense

moneromooo: should have commented it better :3

Because of using randomx in particular ?

ie, it would make sense with, eg, cryptonight ?

Because I don't agree with "mining from an old block makes no sense" in general.

well, cryptonight had no blockchain dependency

Yes. That's why I ask this question.

sorry but I don't see it as valid at all

I do.

miners add to the tip of the chain, that's their job

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.

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

fine. that was the assumption going into writing this code.

OK. Then I think I understand it all now. Thanks for the help.

So I guess I need to remove those tests since they're not meant to pass. Oh well.

hyc: hi. we should collab on something, fam

luigi1111w: do you have time to do CLI merges this weekend? Would like to prepare the next point release soon.

today yes

ty

Hello! Is there any text explaining the format for an XMR address?

This is what I know:

1) It starts with '4' for standard addresses

2) Starts with '8' for derived accounts

3) 95 chars for standard addresses

4) 106 chars for integrated addresses

Are there more rules? Did hear something about the 2. char too?

See monerodocs.org and Zero To Monero 2

monerodocs has a whole page about addresses

selsta: Thanks for that! :-)

Minimons: xmr.llcoins.net

sorry in advance for the meme, it's too good usercontent.irccloud-cdn.com/file/HaxC2aqy/image0-6.jpg

jtgrassie around?