Hello. Can someone look into the C++ code and explain me one thing? I'm not sure why this happened

Should all scalars in the blockchain be stored in their reduced form?

The prover stores them in the reduced form, but the verifier works even if the scalars are not reduced. The tx could have been produced by some custom software.

My Borromean checker is failing on this tx as I always reduce before making any operation. So you are saying that the verifier should work, then I believe that the first operation is a point multiplication with this scalar. (bbs0 * G) what would happen then if bbs0 is not reduced?

This should not give the same as bbs0 reduced

I'm confused, let me think

Since the group is cyclic, scalar multiplication by an unreduced scalar will give the same result as if the scalar was reduced. Unless the implementation requires the scalar to be reduced, which is not the case here.

UkoeHB: Now that 8149 is merged, please disclose the bug (or bugs ? since 8149 mentions multiple fixes) that it fixed.

tevador: Yes, this is true. Let me think why my checker is failing here.

MexicanTakeout96: after release

dangerousfreedom: try inserting a reduce32 in the borromean verifier, and see if the proofs are still valid after reducing scalars

OK 👍 that's fair. TY

UkoeHB: Thats the problem. They are not valid in my verifier. I'm still trying to understand why.

dangerousfreedom: no, I am saying add a step to your borromean verifier that modifies the scalars in the proof with a call to reduce32

I always do that from the beginning. In my implementation it is not possible to have Points outside the prime group or scalars that are not reduced. Which is not the case of Monero apparently.

Let me study this curve again, I'm not sure yet why this is happening or what happens if the scalar is bigger than l but smaller than 2*255-19... I dont fully understand yet

<dangerousfreedom> "Yes, this is true. Let me..." <- I believe this is not true actually.

Ok. Can someone try to multiply these two numbers and tell me the result:

s1 = cb2be144948166d0a9edb831ea586da0c376efa217871505ad77f6ff80f203f8

s2 = e8c079d208b352a71abd36a5deb45c67c276efa217871505ad77f6ff80f20308

aside: I suppose to mean 2^255-19 or 2**255-19

by the point G = 5866666666666666666666666666666666666666666666666666666666666666

hyc: Ok, if he meant 2**255 - 19. I agree.

But I was talking about 'l'

Sorry

I dont get the same results so I think the signature should not match in my verifier. So it is normal.

<dangerousfreedom> "Ok, if he meant 2**255 - 19. I..." <- As reducing means mod 'l' instead of mod p = 2**255-19

d26f7e57bc15161ba4bb93f3f853c293be40dea89094bd6fd5dce10ddd372204

using paste.debian.net/hidden/e0f00deb

So now you can multiply ohters easily :)

I mean the point G

Not the scalar G

The Point G

So an elliptic curve operation

Oh, the G thing is part of the question ?

Yes :P

OK, I see, do two ops, not just a*b.

Yeap :)

Thanks

Two EC multiplicaitons

I get 4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d and 80d08c66c4c26b6cf3b90dfca044cd43be044930b20e6621fa8fd01f1782d748

4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d

80d08c66c4c26b6cf3b90dfca044cd43be044930b20e6621fa8fd01f1782d748

So, different points

But just using my unreliable tools now that I dont perform the mod before :p

Both get me 4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d

Ok, so you are reducing at some point for both

This is what Monero is doing?

Yes, I'm not doing those by hand, I'm reusing monero code ^_^

Hahaha ok thanks

Let me think what is wrong in my code

iirc it had to do with preventing people from spending coinbase outputs too quickly, because in the event of a chain split/large reorg it would cause a big mess: any transactions derived from those coinbase outputs and any transactions using any of those outputs as their decoys would get completely invalidated in a chain reaction

and if I'm not mistaken, the number was picked such that the probability of a reorg that long was below some kind of probability threshold

unfortunately I have no source to back that up though, sorry :(

I've been thinking about this more now, and isn't that just a true for normal outputs? Any transactions referencing any outputs in the reorganized blocks will have their rings invalidated, and that's why we have the 10 block lock.

Is this 60 block lock maybe just leftover from before the 10 block lock was made part of consensus?

The 60 block lock has been around much longer, it's not a leftover