<wfaressuissia[m]> "Are you sure that decoy model..." <- Fwiw, I think this hand-waves over many, many different threat models and isn't really grounded in them

We've grounded ringsize decisions in the past on things like expected chain split impact

It's what we can do at the moment, and despite it not being perfect, it's probably incorrect to imply it's "broken" because it's imperfect, because many use-cases are still accounted for in that setup

<wfaressuissia[m]> "There are too much freedom for..." <- I'm not sure what you're implying here; is this some suggestion to prevent people from making transactions?

I wonder how encrypting transaction lock time would work in practice?

Some sort of zero-knowledge proof where you can go in with a number, the current time, and ask "Is this number still smaller than the lock time?", but without learning the lock time?

Or block numbers of course ...

that is simply a range proof

but obviously you can just iterate it "Is this still smaller than X?" Is this still smaller than X-1? X-2? X-3?

so you can always detect the true value, given enough effort

I think it's more a proof that all inputs in a ring are unlocked between 0 and current height.

Then you cannot try every height, the proof is just valid for a given range chosen by the sender.

Well, I *assume* it's that way, otherise it'd be point.ess

Anyway, now I understand that it's much more complicated than e.g. encrypting payment ids, and drives up verification time and tx size

moneromooo: that is my understanding as well

The sanity check that the CLI wallet now has on lock times is 4 years, I just experienced. Pretty cautious :)