pull down to refresh

An extended relative time lock would be cool: make a wallet with a key that only becomes available to spend after 5 years...like a failsafe key in case you screw everything else up.
I'll be curious to see if pyth gets other interesting use case suggestions. A soft fork for it does seem like a heavy lift.
If I didn’t mess up the math, the limit right now is ~15 months, kinda feels like a bottleneck for other use cases,. Why do you say a softfork for this would be heavy lift?
reply
you didn't mess up the math, the limit is ~455 days or 65535 blocks.
getting people to agree to any change to Bitcoin is difficult. James O'Beirne's Vault proposal is a pretty specific soft fork and can't get very much traction. won't the same be true for a fork like this with such a specific use case?
I'm curious what other use cases you think of for this.
reply
Yeah! You’re right. They could just bundle a bunch of small changes and drop it all at once! Hahaha
Didn’t think of any use cases before, but just thought of one, like giving BTC to a kid and locking it till they hit 18. Same concept could work for when someone retires too.
reply
Like giving BTC to a kid and locking it till they hit 18
You can already do this using CLTV. You can specify a time or block height and make a utxo unspendable until then (100s of years from now if you like).
Locking coins for more than a few years feels risky. What if something changes in Bitcoin between now and the lock time expiry? The Bitcoin wiki on timelocks is good.
reply
Wait, if that’s how it works, then I’m not getting the idea behind timelocks extend. Mind explaining what I’m missing?
reply
i think pyth is talking about extending relative timelocks (using the nSequence field, CSV). these timelocks are called relative timelocks and are different than CLTV timelocks because they are relative to the block when the utxo encumbered by them gets mined. A CLTV timelock references an absolute blockheight or UNIX time.