jberman[m]: Did you get the "Onion Monero Blockchain Explorer" running with your viewtag branch, by any chance? Guess not, but asking is free :)

It does not compile with your branch, and if compiled with the release branch it exits with an error, probably as soon as it touches the first block.

Pretty clear of course that it's the difference in tx structure, but I don't know enough about that explorer to patch it ...

Never mind, got it running

Hi, im having problems with learning LSAG ring signatures and how they are used in monero

I decided to try using "Mastering Monero First Edition", on page 133 and doing the process in a python script to see if I can get it too work

Is there anything else I can reference for this project?

with ringCT this was much easier with the open courseware video that was made xwx

Palladion (he/him): Yes. _Zero to Monero_ is a more technical and more up-to-date reference.

Rucknium[m]1: I been using it, its just not in plain english

I just wanted to see if theres anything else

> <@palladion:cyberia.club> Hi, im having problems with learning LSAG ring signatures and how they are used in monero... (full message at libera.ems.host/_matrix/media/r0/do…06b4a70eb3f1e2459fd21b31cb2508d8445)

wernervasquez[m]: It helped me a lot with stealth addresses and ringCT (although I needed the opencourseware video on it to make an implementation)

I just wanted to know if theres anythign else I should look at

> <@palladion:cyberia.club> I been using it, its just not in plain english

> I just wanted to see if theres anything else

I didn't see you already mentioned it

Palladion (he/him): what is your goal in your learning?

wernervasquez[m]: To make an implmentation in python, same for everything I been doing, honestly this is the last step. I already finished ringCT and stealth addresses

I just want to understand monero better

I also have my own crypto projects im doing but they are just for fun, not an actual project I would have others use

I just do things to learning

Palladionhehim[m: you could look at mechanics of mobilecoin, the chapters on ring sigs are a bit improved compared to ztm

chapter* is*

Thank you

<UkoeHB> "Palladion (he/him): you could..." <- Thanks, I just got a working prototype going

nice :)

Thanks for the update tevador. Btw I found it a bit confusing the distinction between `SecretDerive()` and `KeyDerive()`. Maybe you could call secrets like `k_ga -> s_ga`, `k_et -> s_et`.

And then they would be 'generate-address secret' and 'encrypt tag secret' instead of 'key'. This way the secret/key separation is consistent.

I was thinking the same, but "s" could get confused with the signature "s"

I guess we've run out of alphabet letters...

Personally I would use: `r -> a, R ->A, e -> c, s -> r` there

`c` for challenge, `r` for response, `a` for nonce

and `H_s() -> H_n()` for hash to scalar, so `s` can be 'secret'

Just one question, for LSAG ring signatures, the docs say if c1=c`1

Along with that, c=c` only is valid on the first signature, c1,

So.....do the other signatures not matter? Or am I doing something wrong

`c_1` is the value you get with the original signature, everything else is computed during verification

so you are checking that the 'computed' `c'_1` equals the `c_1` that the prover gave you

i.e. checking that if you start with `c_1`, your computation loop gets you back to `c_1`

A loop like that is only possible if one of the steps started you off with `\alpha G`.

Ah, so in verification you do c_1 first for key_1 in the ring

Then c_1 for key_2? c_2 for key_3? Or do I just throw away everything but c_1

> <@palladion:cyberia.club> Ah, so in verification you do c_1 first for key_1 in the ring

>

> Then c_1 for key_2? c_2 for key_3? Or do I just throw away everything but c_1

Because if I do this then c_x = c_x` for each signature

The signature itself only needs to record `c_1`: `c_1, r_1, r_2, r_3`.

how does it verify the entire ring then if its only doing one signature? why do I find each c_x value if I only use c_1, shouldn't I stop once I get to my real key?

the verifier doesn't know the real one

But the signer does, im just confused why we send values like r_2 if they won't be used

All the responses are needed in order to compute the ring of challenges.

because we just use the keys r

The point is to start at `c_1` and then compute a ring of challenges, and end up back at `c_1`.

wait, do we cycle through the r_x values to find a match?

no, you just compute each challenge in series

So if we have 3 keys in a ring, and we do the challenges, I will be from

c_1->c_2->c_1 or c_1? (like a ring looping back to itself)

s/c_1//

s/or c_1?//

(sorry for asking so many questions, I probably will go back to playing to figure the verifier out soon)

c_2 = h(c_1), c_3 = h(c_1), c_1 = h(c_3)

I call the result `c'_1` since it is a 'nominal' challenge. You have to check that `c'_1` actually is the same as `c_1`.

Still trying to figure this out, I have a 3 key ring, I loop from c'_1 to c'_3... (full message at libera.ems.host/_matrix/media/r0/do…e71142d97ef0565065ced36ad1e6eeae29e)

I know I have this wrong, but im unsure how

* Still trying to figure this out, I have a 3 key ring, I loop from c'_1 to c'_3... (full message at libera.ems.host/_matrix/media/r0/do…3bb8cd37d2d65a991e021094fce55899c85)

`c'_1` takes `r_3` and `c'_3`

Where do I start the loop then?

you compute `c'_2` first

I see

So I do c'_2 with r_1 and Key_1 and c1 from my signature?

yes

Thank you, thats a lot of help

* of help, I didn't realize that when reading the docs