📅 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>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:46:53
in reply to nevent1q…q2zh
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 15:46:53Event JSON
{
"id": "acaf1158fa398d4497fbb7e44edec635bee4651b428067eab06dca1142d2f307",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152813,
"kind": 1,
"tags": [
[
"e",
"6086ec24c7436956a4324b488abdb6aa06edbf1e682d11a0a5b70b6f8e62e6f3",
"",
"root"
],
[
"e",
"cd77cfed82543c2643012432dd7b4c6459e8d6bf2f1944d973ff63c172e47ba2",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-08-25\n📝 Original message:On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Assuming a maximum of 1-year relative lock-times. But what is an\n\u003e appropriate maximum to choose? The use cases I have considered have only\n\u003e had lock times on the order of a few days to a month or so. However I would\n\u003e feel uncomfortable going less than a year for a hard maximum, and am having\n\u003e trouble thinking of any use case that would require more than a year of\n\u003e lock-time. Can anyone else think of a use case that requires \u003e1yr relative\n\u003e lock-time?\n\u003e\n\u003e\nThe main advantage of relative locktime over absolute locktime is in\nsituations when it is not possible to determine when the clock should\nstart. This inherently means lower delays.\n\nAs a workaround, you could chain transactions to extend the relative\nlocktime.\n\nTransaction B has to be 360 days after transaction A and then transaction C\nhas to be 360 days after transaction B and C must be an input into the\nfinal transaction.\n\nThe chain could be built up with multi-sig, like the refund transaction\nsystem, so no one person can create an alternative chain.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150825/dc8e64fa/attachment.html\u003e",
"sig": "0f4c55ca6e3107e2d725f037377791c7284e21ad91ec9c480efe849ea8c7adf21f1ef7bd4766d65fb2d5ecf89efc19b4f9d3d8fe031e7a15e76713b6af5a792d"
}