📅 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 17:34:59
in reply to nevent1q…hh8m
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 17:34:59Event JSON
{
"id": "709fe45a8e0a5476c57ccb47421292c3fb7cf8cc263be4a281c376bd4e922ef9",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686159299,
"kind": 1,
"tags": [
[
"e",
"41b744fb00dece0ad755afb2bd169d7e5d2189a91240037a08b3b215596a998e",
"",
"root"
],
[
"e",
"dcdd011a7b576d4a84b09d3b187b6d2de3b87d08b1690dccd68424aa00348ef4",
"",
"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": "e742e31f068f32c18ad5577488d74123e4246a2014fe3b343d0e53995b8bb2465de3afea9b3e4d5b198a554075792d4d6337d134184933f9ff60b7855af277c1"
}