TimeBounds Ledger Number & Semantic Ledger Time Sorting.

[JeremyRubin]

Currently, the TimePoint data structure used for transaction minTime and maxTime refers to unix time stamps rather than ledger heights. Referring to ledger numbers instead of wall clock times is better for smart contracting applications where the goal is to ensure a number of ledgers (e.g., 1 ledger) between two actions to ensure that they are not ordered incorrectly (assuming they use different source account sequence numbers).

To fix this, I have four proposed amendments:

1. Use the new Transaction formats to permit transactions with ledger number based timeouts instead of wall clock time
2. Use the new Transaction formats to permit transactions with ledger number based timeouts as well as wall clock time
3. Reinterpret TimeBounds to a LedgerNumberBounds if maxTime < minTime, making old transaction format capable of expressing ledger number bounds but also making previously statically provably invalid transactions valid
4. Semantic Ledger Time Sorting (see Semantic Ledger Time Sorting #291, separate issue as it was sufficiently complicated to merit separate discourse).

Overall, my favor goes to solution 2, then 1, then 3 but I understand there may be alternative preferences based on complexity of implementation. 4 should be considered separately, as it would be in parallel to one of these three.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 5 days unless the stale label is removed, or a comment is posted.

[MonsieurNicolas]

Might want to think about this in the context of transactions gated on balance entries, which allows for relative time locks as well.