#Is the expiration ledger inclusive or exclusive?

49 messages · Page 1 of 1 (latest)

tawdry portal
#

If data has an expiration ledger of N, clearly the data is usable when the ledger number is less than N, but what about when the ledger number is equal to N?

cc @rare parrot

#

I expect the data would still be usable in ledger N, and would become unusable in ledger N+1, because it's more natural – speaking subjectively – to speak about periods of validity where the end is through / inclusive, rather than speak about periods of validity by specifying a value past the end of the validity.

somber narwhal
#

that's my expectation as well

#

and I've relied on that for nonces

tawdry portal
somber narwhal
#

also, another question on the same topic: if I create a default persistent entry on ledger N, then is expiration ledger N+4096 or N + 4095, i.e. do we count the current ledger when computing the bump ledger?

rotund kettle
rare parrot
#

Correct, entry is live iff currentLedger < expirationLedger, entry is expired iff currentLedger >= expirationLedger according to my core PRs

#

My thinking is that the entry expires exactly on the expirationLedger, not after

somber narwhal
#

ugh

#

we need to fix this for auth then

#

though maybe we should treat it inclusive

#

I agree with Leigh that exclusive boundaries are easier to mess up

tawdry portal
#

Well, exclusive ranges are really good in a lot of places though, like slicing data, bounds on arrays, etc.

rare parrot
#

I'm not married to this either, it's just what I've been doing

tawdry portal
#

But when I think natural world examples of expiry, usually expiry is really defining a validity period.

#

E.g. credit card are valid in the month they expire.

#

E.g. passports are valid on the date they expire.

somber narwhal
#

what about my other question btw?

#

as we all know, off-by-one errors are one of the two hardest problems in software...

tawdry portal
#

E.g. drivers licenses (in California at least) are valid on the date they exipre.

rotund kettle
somber narwhal
#

but since it's exclusive, the entry will live 4095 more ledgers, right?

rotund kettle
#

Where N is the ledger before your tx was applied

somber narwhal
#

hmm, that's actually interesting

#

do we pass LCL or 'current' ledger to contracts?

#

I think we should do current

#

the same goes for the time

rotund kettle
#

Yeah I was just looking into this. I think there's a bug in either this code, or the bumpm/restore ops

#

the ops use ltx.loadHeader().current().ledgerSeq, which is the ledger being applied

somber narwhal
#

is it though?

#

when do we bump the ledger seq?

rotund kettle
somber narwhal
#

ok, cool

#

so the entry will live for 4096 ledgers counting the one when it was created... which seems ok

rotund kettle
#

Which uses the last closed ledger

#

Unless I'm reading this wrong

somber narwhal
#

oh

#

that's annoying

rotund kettle
#

Yeah I'm thinking that line should be updated to use the current ledger num

rotund kettle
#

@rare parrot what do you think about using the current ledger in applyExpirationBumps?

rare parrot
#

Sounds fine, current ledger is lcl + 1 right?

rotund kettle
#

Yeah it's also what's stored in ltx.loadHeader().current() during transaction application which is what we use in the bump/restore ops and pass to the host.

#

So did we come to consensus on if it should be inclusive vs exclusive? @tawdry portal?

tawdry portal
#

I haven't been able to think of a real world situation of something that expires, and isn't usable on the expiry date.

somber narwhal
#

that also needs to be consistent with approve and signature expiration

rotund kettle
#

Ok I think inclusive makes sense and should be easy to switch. @rare parrot can update the logic in in his PR, and I'll update the allowance PR. Any objections?

rare parrot
#

Sounds good to me, just to double check, new behavior is isEntryLive == currentLedger <= expirationLedger