16:23:26 <dangerousfreedom> Hello. Can someone look into the C++ code and explain me one thing? I'm not sure why this happened
16:23:32 <dangerousfreedom> https://github.com/monero-project/monero/issues/8438
16:25:03 <dangerousfreedom> Should all scalars in the blockchain be stored in their reduced form?
16:44:37 <tevador> 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.
17:12:13 <dangerousfreedom> 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?
17:13:39 <dangerousfreedom> This should not give the same as bbs0 reduced
17:14:33 <dangerousfreedom> I'm confused, let me think
17:20:02 <tevador> 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.
17:20:46 <MexicanTakeout96> UkoeHB: Now that 8149 is merged, please disclose the bug (or bugs ? since 8149 mentions multiple fixes) that it fixed.
17:21:28 <dangerousfreedom> tevador: Yes, this is true. Let me think why my checker is failing here.
17:24:19 <UkoeHB> MexicanTakeout96: after release
17:26:14 <UkoeHB> dangerousfreedom: try inserting a reduce32 in the borromean verifier, and see if the proofs are still valid after reducing scalars
17:27:05 <MexicanTakeout96> OK 👍 that's fair. TY
17:28:09 <dangerousfreedom> UkoeHB: Thats the problem. They are not valid in my verifier. I'm still trying to understand why.
17:50:18 <UkoeHB> dangerousfreedom: no, I am saying add a step to your borromean verifier that modifies the scalars in the proof with a call to reduce32
17:51:45 <dangerousfreedom> 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.
17:56:38 <dangerousfreedom> 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
18:10:47 <dangerousfreedom> <dangerousfreedom> "Yes, this is true. Let me..." <- I believe this is not true actually.
18:16:05 <dangerousfreedom> Ok. Can someone try to multiply these two numbers and tell me the result:
18:16:13 <dangerousfreedom> s1 = cb2be144948166d0a9edb831ea586da0c376efa217871505ad77f6ff80f203f8
18:16:20 <dangerousfreedom> s2 = e8c079d208b352a71abd36a5deb45c67c276efa217871505ad77f6ff80f20308
18:16:32 <hyc> aside: I suppose to mean 2^255-19 or 2**255-19
18:16:43 <dangerousfreedom> by the point G = 5866666666666666666666666666666666666666666666666666666666666666
18:17:48 <dangerousfreedom> hyc: Ok, if he meant 2**255 - 19. I agree.
18:18:07 <dangerousfreedom> But I was talking about 'l'
18:18:10 <dangerousfreedom> Sorry
18:19:36 <dangerousfreedom> I dont get the same results so I think the signature should not match in my verifier. So it is normal.
18:23:03 <dangerousfreedom> <dangerousfreedom> "Ok, if he meant 2**255 - 19. I..." <- As reducing means mod 'l' instead of mod p = 2**255-19
18:23:54 <moneromooo> d26f7e57bc15161ba4bb93f3f853c293be40dea89094bd6fd5dce10ddd372204
18:24:58 <moneromooo> using https://paste.debian.net/hidden/e0f00deb/
18:25:27 <moneromooo> So now you can multiply ohters easily :)
18:26:08 <dangerousfreedom> I mean the point G
18:26:09 <dangerousfreedom> Not the scalar G
18:26:15 <dangerousfreedom> The Point G
18:26:29 <dangerousfreedom> So an elliptic curve operation
18:26:49 <moneromooo> Oh, the G thing is part of the question ?
18:27:05 <dangerousfreedom> Yes :P
18:27:13 <moneromooo> OK, I see, do two ops, not just a*b.
18:27:29 <dangerousfreedom> Yeap :)
18:27:31 <dangerousfreedom> Thanks
18:27:38 <dangerousfreedom> Two EC multiplicaitons
18:28:08 <dangerousfreedom> I get 4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d and 80d08c66c4c26b6cf3b90dfca044cd43be044930b20e6621fa8fd01f1782d748
18:28:19 <dangerousfreedom> 4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d
18:28:24 <dangerousfreedom> 80d08c66c4c26b6cf3b90dfca044cd43be044930b20e6621fa8fd01f1782d748
18:28:32 <dangerousfreedom> So, different points
18:29:04 <dangerousfreedom> But just using my unreliable tools now that I dont perform the mod before :p
18:30:22 <moneromooo> Both get me 4014ab9200745ab76fab92fb92c6ba162372c8449b8cbd5485f4676c2d823a0d
18:31:03 <dangerousfreedom> Ok, so you are reducing at some point for both
18:31:11 <dangerousfreedom> This is what Monero is doing?
18:31:29 <moneromooo> Yes, I'm not doing those by hand, I'm reusing monero code ^_^
18:31:43 <dangerousfreedom> Hahaha ok thanks
18:31:52 <dangerousfreedom> Let me think what is wrong in my code
18:32:05 <moneromooo> https://paste.debian.net/hidden/28042fe6/
20:19:06 <UkoeHB> https://github.com/monero-project/research-lab/issues/104
21:00:47 <merope> 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
21:01:28 <merope> 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
21:02:18 <merope> unfortunately I have no source to back that up though, sorry :(
22:49:55 <BusyBoredom[m]> 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. 
22:49:55 <BusyBoredom[m]> Is this 60 block lock maybe just leftover from before the 10 block lock was made part of consensus? 
23:24:58 <merope> The 60 block lock has been around much longer, it's not a leftover