00:01:46 <BusyBoredom[m]> That's what I mean, maybe it was an early attempt at patching the reorg issue from a time when reorgs were more common and we didn't have a universal 10 block lock. And maybe now that we have 2 minute block times and a universal 10 block lock, maybe it's not needed anymore (hence me calling it a leftover). 
00:01:46 <BusyBoredom[m]> I'm AFK though so I haven't gotten to look at when it was put in place yet, I'm just throwing a theory out there. 
00:26:52 <BusyBoredom[m]> Looks like it was 10 blocks before the 2014 bitmonero release. Here's the commit: https://github.com/monero-project/monero/commit/1a8f5ce89a990e54ec757affff01f27d449640bc#
01:17:50 <ofrnxmr[m]> Perhaps redundant then? And only there as an early safeguard?
01:18:12 <ofrnxmr[m]> Disclaimer: didnt click link yet
01:25:08 <BusyBoredom[m]> Yeah, that's what I'm thinking. 
01:25:09 <BusyBoredom[m]> In his initial 2014 bitmonero release forking bytecoin, thankful_for_today made the decision to increase the coinbase unlock time from 10 to 60 to make up for decreasing the block time from 2 minutes to 1 minute. When asked about it by a confused miner, he said "60 blocks unlock delay. This is much safer." with no further clarification: https://bitcointalk.org/index.php?topic=563821.msg6283927#msg6283927
01:25:09 <BusyBoredom[m]> We now have a 2 minute block time again, so I don't see anything wrong with returning to the 10 block unlock time again as well. I'm gonna dig a little more to see if I can find any deeper justification for thankful_for_today's 6x increase in the unlock time though. 
01:45:51 <UkoeHB> BusyBoredom[m]: good research, perhaps it has no deeper meaning beyond thankful_for_today's hunch
01:47:52 <BusyBoredom[m]> Thanks :) I stuck the links on your github issue too so they don't get lost. 
07:31:56 <merope> The 10 block lock is about privacy though, nothing to do with preventinf reorg issues
07:46:08 <sech1> Does Bitcoin have lock time for coinbase coins? I checked the BTC explorer and couldn't find instances where coinbase coins were spent less than 100 blocks after they were mined.
07:46:23 <sech1> Maybe the reason for this can be found in early BTC discussions
08:01:00 <sech1> https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h#L18
08:02:58 <sech1> "This is a safeguard to prevent outputs that originate from the coinbase transaction from becoming unspendable (in the event the mined block moves out of the active chain due to a fork)."
08:03:58 <sech1> https://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time
08:10:29 <sech1> So my understanding of all this that 11 block reorg in Monero would cause the same damage as 101 block reorg in Bitcoin because transactions will become invalid and unmineable. In Monero, they'll become unmineable because of changed output indices, in Bitcoin, they'll become unmineable because of disappeared coinbase coins.
08:10:45 <sech1> Which makes 60 block coinbase lock time useless
08:10:49 <sech1> 10 block lock time is enough
08:13:17 <sech1> on the other hand, is it really a pressing issue? Miners can wait 60 blocks
11:15:58 <selsta> sech1: quite sure this topic came up because of Seraphis related changes
11:16:08 <selsta> not because miners can't wait 60 blocks
11:18:37 <tevador> UkoeHB: would it be acceptable to have a tiny chance that Jamtis address generation fails? That chance would be (ℓ-2**252)/ℓ, approx. 1 in 2**128.
11:21:07 <tevador> This would happen with x25519 if k_a^j**(-1) >= 2**252. x25519 implementations use key clamping and won't work with keys >= 2**252.
12:23:42 <UkoeHB> tevador: idk if it's possible due to the unlock amounts key
12:23:59 <UkoeHB> https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4204089#gistcomment-4204089
12:24:45 <UkoeHB> which is not known to an address generator
12:26:14 <UkoeHB> not possible for the user to know about ahead of time*
12:31:31 <UkoeHB> also, wouldn't it be a failure rate of 50%?
12:34:14 <tevador> why 50%? ℓ = 2**252 + 27742317777372353535851937790883648493
12:43:48 <UkoeHB> ah it's probably way worse than 50%, because they modify 5 bits in total (bit 256 -> 0, bit 255 -> 1, bits 1-3 -> 0)
12:44:23 <UkoeHB> after modifying those, the chance you end up with the original scalar is low..
12:45:13 <tevador> No, we can work around the clamping.
12:45:59 <tevador> we can't set bit 254 to 1, but the bits 0-2 must stay 0 to remove the cofactor
12:46:26 <tevador> so we can define out key to be made of bits 3-254
12:46:38 <UkoeHB> ok but what about the unlock amounts key?
12:46:58 <tevador> This is the problem. With the new scheme, we actually need to invert k^j_a * k_ua.
12:49:19 <UkoeHB> is there any way to remove the clamping? or is it baked into the assembly implementations...
12:50:33 <tevador> the arm implementation has that baked in, but I've already removed the setting of bit 254 to 1.
12:50:39 <tevador> this line: orr x3, x3, #0x4000000000000000
12:51:44 <UkoeHB> it should be fairly cheap to multiply the input key by 8 with sc_mul() before doing the point multiplication
12:52:15 <tevador> no need for that, all we need is to modify the inversion function
12:53:39 <tevador> my inversion function actually returns 8/(64*k^j_a)
12:54:02 <tevador> that works out to correctly cancel the key
12:54:10 <UkoeHB> hm
12:54:53 <tevador> it only fails if 1/(64*k^j_a) is more than 252 bits
12:56:06 <tevador> with the modified scheme that would be 1/(512*k^j_a*k_ua)
12:56:13 <UkoeHB> are you still bit-setting the lowest 3 bits?
12:56:59 <tevador> all keys are already multiples of 8, so they have the lowest 3 bits cleared
12:58:01 <tevador> note that 8/(512*k^j_a*k_ua) is a multiple of 8
12:58:44 <UkoeHB> unless I'm missing something, not all multiples of 8 in the scalar field have the lowest 3 bits zeroed
12:58:45 <tevador> that last multiplication is simply a bit shift of the 252-bit inverted value
12:59:18 <UkoeHB> ah you are bit-shifting?
12:59:19 <tevador> 1. you calculate 1/(512*k^j_a*k_ua) 2. you bit shift left by 3
12:59:27 <tevador> the result is 8/(512*k^j_a*k_ua) 
12:59:47 <tevador> you can plug that in the normal x25519 function and it works
12:59:59 <UkoeHB> it's a bit confusing for me since in my mind all scalars are mod l
13:00:18 <UkoeHB> but that sounds like it would work
13:00:22 <tevador> yes, x25519 works with scalars > ℓ
13:02:12 <tevador> the only problem is that the address generator has no way to know if 1/(512*k^j_a*k_ua) overflows
13:03:59 <tevador> but the chance is very minuscule, maybe it can be simply ignored
13:04:44 <UkoeHB> if the chance is minuscule, why not remove the associated clamp?
13:08:58 <UkoeHB> I guess it's possible the implementations don't support scalars with the last bit set..
13:09:08 <UkoeHB> and it just blows up
13:16:58 <tevador> It's not about the clamp. x25519 implementations don't support keys larger than 2**255
13:17:37 <tevador> if the inversion is >= 2**252, you will exceed 2**255 after shitfing by 3 bits
13:19:38 <UkoeHB> what happens if the lowest 3 bits are set? e.g. call sc_reduce32() after bit shifting
13:20:39 <tevador> the lowest 3 bits need to be 0 to clear the (possible) cofactor from the base point
13:21:10 <tevador> a malicious sender could give you a key that has a torsion component
13:28:53 <UkoeHB> ahh ok, because the torsion elements have a different group order, you can't do mod l and retain the 8
13:32:49 <UkoeHB> if by chance your input key >= 2^252, it should be possible to branch into a 'mul key then mul 8' alternative
13:34:03 <UkoeHB> having that branch in the key derivation function should make it simpler to implement address generation as well
13:34:14 <tevador> Yes, it's a soft failure. The funds would not be lost.
15:10:29 <selsta> dangerousfreedom: https://github.com/monero-project/monero/issues/8438 <-- can this be closed?
15:26:09 <dangerousfreedom> <selsta> "dangerousfreedom: https://github..." <- I will give a better answer as soon as I understand exactly why that happened. I am still not sure. I will do it this week.