Describe the feature
Apparently Elements has a mechanism called setmocktime where we can make it apply a specified timestamp when mining new blocks on a chain. This is very helpful for simulating the passage of realtime, and in particular for testing anything having to do with the blockchain's notion of time.
I have an upcoming standard library PR with some timelock features. I was able to test quite a lot of cases, including some related to realtime, but I couldn't readily test the happy path for successful timelock exercise, because I don't want to make the test wait 512 seconds (the minimum interval for this timelock!) of realtime in order to confirm that the transaction succeeded. Apparently with the mocktime stuff in Elements, if it were exposed through Simplex, we could do this because we could mine the original transaction "far in the past" and then mine a bunch of present-time stuff on top of it, or perhaps mine the original transaction "in the present" and then mine a bunch of mock-future stuff on top of it, thereby convincing Elements that the timelock conditions were satisfied.
I think this is a pretty straightforward thing to expose along the lines of other Elements mining features that Simplex currently exposes; it's just one that hasn't been needed before.
Probably this will also become useful for some kinds of contract tests, depending on which form of timelock they use, as it would enable real contracts to add Simplex tests more realistically simulating things like the expiration of a loan or an option (if that expiration happened to be specified as a Duration in Simplicity terms).
Describe the feature
Apparently Elements has a mechanism called
setmocktimewhere we can make it apply a specified timestamp when mining new blocks on a chain. This is very helpful for simulating the passage of realtime, and in particular for testing anything having to do with the blockchain's notion of time.I have an upcoming standard library PR with some timelock features. I was able to test quite a lot of cases, including some related to realtime, but I couldn't readily test the happy path for successful timelock exercise, because I don't want to make the test wait 512 seconds (the minimum interval for this timelock!) of realtime in order to confirm that the transaction succeeded. Apparently with the
mocktimestuff in Elements, if it were exposed through Simplex, we could do this because we could mine the original transaction "far in the past" and then mine a bunch of present-time stuff on top of it, or perhaps mine the original transaction "in the present" and then mine a bunch of mock-future stuff on top of it, thereby convincing Elements that the timelock conditions were satisfied.I think this is a pretty straightforward thing to expose along the lines of other Elements mining features that Simplex currently exposes; it's just one that hasn't been needed before.
Probably this will also become useful for some kinds of contract tests, depending on which form of timelock they use, as it would enable real contracts to add Simplex tests more realistically simulating things like the expiration of a loan or an option (if that expiration happened to be specified as a
Durationin Simplicity terms).