last_will example assumes wrong block duration for Elements

[schoen]

Project version

0.7.0

Project

other

What happened?

The last_will.simf declares a Distance value

    let days_180: Distance = 25920;

However, this is 180 days only if this contract were running on Bitcoin Core where the average blocktime is 10 minutes (259200 minutes is 180 days). On Elements, the blocktime is 1 minute, so the inheritor can actually inherit in this example after 18 days of testator inactivity, not 180 days.

The maximum time that can be asserted on Elements with a Distance is 65535 blocks of 1 minute each, or about 45.5 days. Beyond that, one would use a Duration instead. See the timelock documentation for details.

Minimal reproduction steps

See timelocks documentation and compare to last_will.simf code.

[stringhandler]

Interesting. A user could check for the correct chain using jet::genesis_block_hash() and write a script that runs on both networks.

This is a good candidate to be added to the pitfalls document.

I wonder if it is worth adding a warning to the compiler whenever this jet is used to say that this value has different times on different networks

[apoelstra]

I don't think we should be doing on-chain checks for stuff like this. We may want to add something to SimplicityHL to specify timelock times. While we're at it, maybe we could prevent people from mixing height-based and time-based timelocks in ways that would result in unspendable programs.