-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: invalid-hereafter upper limit #83
Comments
Indeed! Good idea. And it's even more complicated than that as this constraint only exists for transactions that carry Plutus scripts! Transactions without scripts can have arbitrarily far away TTL since the problem really only occurs when a conversion to POSIX time is needed (for Plutus scripts execution). Also, the window happens to be larger near hard-fork boundary as well. As soon as the global parameter for the next era are known, the stability windows is extended by another window (since no hard fork can happen immediately after the current one). but I am not sure this edge case is worth mentioning 😅 ... |
I was not aware of this edge case. Thanks for mentioning it! Considering the window is currently 1.5 days and the typical lifetime of a transaction in a mempool is a few hours at most, I don't think most users will ever need to take advantage of the extra window around hardfork events. Perhaps the edge case could still be mentioned in a sentence or two within a footnote. That way it is there if someone actually does need that information. EDIT: I just saw the source code I linked has a brief discussion (above the linked line) about extending around the hardforks. Perhaps the footnote can just link to this source file for "further reading". |
This idea pertains to the aiken documentation's What I Wish I Knew section, specifically the Validity Intervals sub-section.
There is a maximum upper-bound allowed for validity intervals of 1.5 days (129600 slots) past the current slot. If you set an invalid-hereafter to be later than this bound, you will get a
PastHorizon
error message when submitting the transaction. It took me a while to figure this out and I wish I knew it before 😅The value of 1.5 days is calculated by:
stability_window_network_parameter * 2
(source). From the comment in the code (a few lines below the linked source code line):Hardforks can alter the slot <--> POSIXTime conversions and so the node rejects conversions that are too far into the future.
Users can still set expirations (in datums) for things that exceed the current 1.5 days bound; but when actually specifying the validity interval for a transaction, the upper bound must currently be
min(129600 + current_slot, expiration_slot)
.An example use case is a loan's expiration: the upper-bound can be used to prove the loan's expiration has not passed yet, but loans can last for months. So when trying to prove the loan is not expired, the transaction must use
current_slot + 129600
for the upper bound until the actual expiration is within 1.5 days of the current slot.The text was updated successfully, but these errors were encountered: