<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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 &gt;1yr relative lock-time?<br></div><br></div></blockquote><div><br></div><div>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.<br><br></div><div></div>As a workaround, you could chain transactions to extend the relative locktime.<br><div><br></div><div>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.<br><br>The chain could be built up with multi-sig, like the refund transaction system, so no one person can create an alternative chain.<br></div></div></div></div>