.merges

so when are we dropping tx_extra?

or in general, the stuff described here: monero-project/monero #6456

monero-project/monero #6812 needs a review

also I assume the timelock PR needs extra work and will not be included this HF?

Depends if problems are found with it. The latest talk was really how to add more stuff that's really irrelevant IMHO.

I'll go in if several people want it in though.

Anyway, I guess it gets bumped to next version if there's still discussion about it.

I would like to branch in ~2 days, so if it gets solved until then it can get included

xiphon: opinion on recent comments? ^

Do people expect people to lock to a time rather than blocks for times that are really close ?

which people?

Do people here think people who use monero wold lock to a time rather than blocks for times that are really close ?

I mean, the precision discussion seems really not relevant for times into the future, only for short lock times.

and whatever we do, it'll be approximate if there is to be any consensus.

(distributed consensus)

Not sure I understand... it doesn't really matter what we expect people to use timelocks for. If we have a time-base timelock, then we might as well put some effort into making it precise based on the on-chain information available.

AFAICT, it's not precise, it's... guess at another thing that may or may not be closer to the time.

Maybe it has more probability to be closer, but it's still a bit of a shot in the dark, no ?

(and this is not me saying I won't add it, I'll add it if people here generally think it's best, I'm just not convinced it's more than extra code that doesn't really help)

Well... the '+1' is a fix so the behavior matches the intention (projecting to the current block time correctly), and the min(projected median, prev block + 1) is a safety improvement that reduces how often and how severely the adjusted time will be in the future.

Hmm, I'm just thinking that a block's timestamp may not be less than the median of the last N blocks, can it. In which case this does make sense...

Assuming the N agrees betewen both.

Of course, a lot more effort could be made to increase precision and/or reduce safety risks. So it is subjective how far you can go. My subjective opinion is my suggestion is far enough, enough so that adjusted times computed are within the variance of local time.

Do you know offhand if the consensus allowed timestamp matches the last N blocks ?

(for the same N)

Although I guess modern clocks aren't that variant, since they are all synchronized...

I think I'm confusing with difficulty, which is 720 with a delay of some number of blocks...

The time stamp must be greater than the median of the last 60 blocks, and less than local time + 2hr

And 60 blocks is what this unlock code checks for too, right ?

Yes it uses the same preprocessor constant

OK. I think I'm convinced now that the min is actually a good idea after all.

Sorry :)

No problem, thanks for being skeptical :)