15:22:51 <sgp_[m]> <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
15:23:34 <sgp_[m]> We've grounded ringsize decisions in the past on things like expected chain split impact
15:24:47 <sgp_[m]> 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
15:25:53 <sgp_[m]> <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?
18:00:59 <rbrunner> I wonder how encrypting transaction lock time would work in practice?
18:01:23 <rbrunner> 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?
18:02:10 <rbrunner> Or block numbers of course ...
18:02:53 <hyc> that is simply a range proof
18:04:02 <hyc> but obviously you can just iterate it "Is this still smaller than X?" Is this still smaller than X-1? X-2? X-3?
18:04:20 <hyc> so you can always detect the true value, given enough effort
18:05:26 <moneromooo> I think it's more a proof that all inputs in a ring are unlocked between 0 and current height.
18:05:51 <moneromooo> Then you cannot try every height, the proof is just valid for a given range chosen by the sender.
18:06:04 <moneromooo> Well, I *assume* it's that way, otherise it'd be point.ess
18:14:49 <rbrunner> Anyway, now I understand that it's much more complicated than e.g. encrypting payment ids, and drives up verification time and tx size
18:18:57 <UkoeHB> moneromooo: that is my understanding as well
18:22:53 <rbrunner> The sanity check that the CLI wallet now has on lock times is 4 years, I just experienced. Pretty cautious :)