MIME-Version: 1.0
In-Reply-To: <CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
	<CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com>
	<CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com>
	<CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com>
	<55DA6470.9040301@thinlink.com>
	<CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com>
	<CABm2gDqW7OGuyZ1BTTeeivDf9wFVsAK9AaGYm8XWwLb2O2Lb+g@mail.gmail.com>
	<CAOG=w-ubk3nPfxy25Hd6kPeehf7vnYD5chksLWU5wU2t=jL5TA@mail.gmail.com>
	<CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com>
Date: Tue, 25 Aug 2015 23:36:23 +0100
Message-ID: <CAE-z3OVFiiDmjVTnFZPTQEbRQK69ZiVkHwXrJ4QS211JeTb9=w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113ad6482602ff051e2a5d4c
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
 relative locktime
Precedence: list

--001a113ad6482602ff051e2a5d4c
Content-Type: text/plain; charset=UTF-8

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.

--001a113ad6482602ff051e2a5d4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Assum=
ing a maximum of 1-year relative lock-times. But what is an appropriate max=
imum 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 uncomfortab=
le going less than a year for a hard maximum, and am having trouble thinkin=
g of any use case that would require more than a year of lock-time. Can any=
one 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 relat=
ive locktime over absolute locktime is in situations when it is not possibl=
e to determine when the clock should start.=C2=A0=C2=A0 This inherently mea=
ns lower delays.<br><br></div><div></div>As a workaround, you could chain t=
ransactions to extend the relative locktime.<br><div><br></div><div>Transac=
tion 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 tran=
saction.<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>

--001a113ad6482602ff051e2a5d4c--