On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days to a month or so. However I would feel uncomfortable going less than a year for a hard maximum, and am having trouble thinking of any use case that would require more than a year of lock-time. Can anyone else think of a use case that requires >1yr relative lock-time?


The main advantage of relative locktime over absolute locktime is in situations when it is not possible to determine when the clock should start.   This inherently means lower delays.

As a workaround, you could chain transactions to extend the relative locktime.

Transaction B has to be 360 days after transaction A and then transaction C has to be 360 days after transaction B and C must be an input into the final transaction.

The chain could be built up with multi-sig, like the refund transaction system, so no one person can create an alternative chain.