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

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.

Looks like it was 10 blocks before the 2014 bitmonero release. Here's the commit: monero-project/monero 1a8f5ce#

Perhaps redundant then? And only there as an early safeguard?

Disclaimer: didnt click link yet

Yeah, that's what I'm thinking.

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: bitcointalk.org/index.php?topic=563821.msg6283927#msg6283927

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.

BusyBoredom[m]: good research, perhaps it has no deeper meaning beyond thankful_for_today's hunch

Thanks :) I stuck the links on your github issue too so they don't get lost.

The 10 block lock is about privacy though, nothing to do with preventinf reorg issues

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.

Maybe the reason for this can be found in early BTC discussions

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

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.

Which makes 60 block coinbase lock time useless

10 block lock time is enough

on the other hand, is it really a pressing issue? Miners can wait 60 blocks

sech1: quite sure this topic came up because of Seraphis related changes

not because miners can't wait 60 blocks

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.

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.

tevador: idk if it's possible due to the unlock amounts key

which is not known to an address generator

not possible for the user to know about ahead of time*

also, wouldn't it be a failure rate of 50%?

why 50%? ℓ = 2**252 + 27742317777372353535851937790883648493

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)

after modifying those, the chance you end up with the original scalar is low..

No, we can work around the clamping.

we can't set bit 254 to 1, but the bits 0-2 must stay 0 to remove the cofactor

so we can define out key to be made of bits 3-254

ok but what about the unlock amounts key?

This is the problem. With the new scheme, we actually need to invert k^j_a * k_ua.

is there any way to remove the clamping? or is it baked into the assembly implementations...

the arm implementation has that baked in, but I've already removed the setting of bit 254 to 1.

this line: orr x3, x3, #0x4000000000000000

it should be fairly cheap to multiply the input key by 8 with sc_mul() before doing the point multiplication

no need for that, all we need is to modify the inversion function

my inversion function actually returns 8/(64*k^j_a)

that works out to correctly cancel the key

hm

it only fails if 1/(64*k^j_a) is more than 252 bits

with the modified scheme that would be 1/(512*k^j_a*k_ua)

are you still bit-setting the lowest 3 bits?

all keys are already multiples of 8, so they have the lowest 3 bits cleared

note that 8/(512*k^j_a*k_ua) is a multiple of 8

unless I'm missing something, not all multiples of 8 in the scalar field have the lowest 3 bits zeroed

that last multiplication is simply a bit shift of the 252-bit inverted value

ah you are bit-shifting?

1. you calculate 1/(512*k^j_a*k_ua) 2. you bit shift left by 3

the result is 8/(512*k^j_a*k_ua)

you can plug that in the normal x25519 function and it works

it's a bit confusing for me since in my mind all scalars are mod l

but that sounds like it would work

yes, x25519 works with scalars > ℓ

the only problem is that the address generator has no way to know if 1/(512*k^j_a*k_ua) overflows

but the chance is very minuscule, maybe it can be simply ignored

if the chance is minuscule, why not remove the associated clamp?

I guess it's possible the implementations don't support scalars with the last bit set..

and it just blows up

It's not about the clamp. x25519 implementations don't support keys larger than 2**255

if the inversion is >= 2**252, you will exceed 2**255 after shitfing by 3 bits

what happens if the lowest 3 bits are set? e.g. call sc_reduce32() after bit shifting

the lowest 3 bits need to be 0 to clear the (possible) cofactor from the base point

a malicious sender could give you a key that has a torsion component

ahh ok, because the torsion elements have a different group order, you can't do mod l and retain the 8

if by chance your input key >= 2^252, it should be possible to branch into a 'mul key then mul 8' alternative

having that branch in the key derivation function should make it simpler to implement address generation as well

Yes, it's a soft failure. The funds would not be lost.

dangerousfreedom: monero-project/monero #8438 <-- can this be closed?

<selsta> "dangerousfreedom: 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.