Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-25 📝 Original message:On Tue, Aug 25, 2015 at ...

📅 Original date posted:2015-08-25
📝 Original message:On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150825/dc8e64fa/attachment.html>;