So here's the deal: I'm trying to find a way in Bitcoin to lock my funds for a specific duration and have them automatically released once that time is up. Usually, with time-locked transactions like HTLCs, you need to do a second transaction to either get your funds or get a refund. I'm curious if there's a method to make the unlocking happen automatically without needing another transaction.
So my question is: Is there any existing method or script in Bitcoin that lets you lock funds for a set period and then automatically unlock them without needing a second transaction for a refund? If not, what are some alternatives or workarounds to get this kind of functionality in Bitcoin?
It is technical, you should read from this article and see how you can set a timelock for your transaction as everything is explained on this link.
https://learnmeabitcoin.com/technical/transaction/input/sequence/#relative-locktime
What you describe is partially what is considered to be covenants. No, it is not possible to "automatically unlock" an output, unless you clarify more what you're trying to accomplish.
The only alternative is to create UTXO A, sign a transaction that spends UTXO A after a particular block height, then delete the wallet and keep that transaction until you broadcast it after the specified block height. But please tell us what you're trying to accomplish, because this is not recommended to do.
You cannot just lock and automatically unlock your BTC, however, whatever you are planning to do looks like what could get you in trouble and make you lose your BTC. Why do you want to lock and automatically unlock your BTC, what are you looking to achieve here. You should provide more details so you can get the best recommendation for the safety of your funds.
This case comes to mind: the guy made a mistake, and locked his 0.5BTC for 125 years. That topic is a good start for what you want (and the OP is archived here).
Note: you should be very careful and only do this if you really know what you're doing!
Using Locktime for inheritance planning, backups or gifts.
Lock time.
Locktime is for you, guide is there for you, but you must be very careful in using it for locking your bitcoin. Make sure you do it right, and before that make sure that you have very good finance management. I mean by locking your bitcoin, you need to have very good finance, enough in saving for emergency and you are sure that you won't need to touch these locked bitcoin in future because of emergency. And make sure that not only you but your loved ones can access it, if you unfortunately pass away whatsoever reasons.
Alternative (to the use of nLockTime) option is to create decaying multisyg transaction which sets the threshold for number of keys required to unlock sent fund after given period of time (for instance, one may create let's say 2-of-2 multisig with one key decayed after X days , throw away (optionally) this key and unlock fund with remaining key after expired time-limit). But this is more complicated approach (compared with the single nLockTime) which has to be used only by the savvy user who knows what he is doing.
I don't get the context.
You will need to spend the unspent transaction output(s) whether it has locktime or not, thus, create an additional transaction to unlock it.
Basically:
Normal: Funds---transaction--->Normal output script---transaction--->refund
Locked: Funds---transaction--->Locked output script---transaction--->refund
This is only doable if the "Funds" above isn't actually spent; like a simple transaction with "nlocktime" set.
But that can't be broadcast until the locktime has passed so you can still (accidentally) spend its input to another transaction, once confirmed it will invalidate the locked txn.
All you can do is keep it locally in the wallet and mark the inputs "to-be-spent" by that transaction. (just client side)
It's not automatic but "claim" involves only one txn (broadcast the transaction) and refund involves no transaction (delete the transaction).
CLTV (OP_CHECKLOCKTIMEVERIFY) or CSV (OP_CHECKSEQUENCEVERIFY) already do what you want to achieve: In both cases, you lock the funds with a transaction either for X blocks after confirmation (CSV) or until a specified block or time (CLTV). After the timelock has passed, you can spend them again -- no "refund" transaction is required.
You could say they're automatically "unlocked": While they are locked, miners will refuse to include any transaction spending these funds. But once the timelock block has been reached, you can spend the funds again.
CLTV/CSV can be a component of HTLCs. I think you may be confused due to the way Lightning works, where you indeed would need to push a transaction on-chain for a "refund" in some cases.
To add to d5000's reply:
To use OP_CHECKLOCKTIMEVERIFY and create a time locked address, you can use the tool provided by coinb.in.
Generate a pair of private and public keys somewhere else. Enter that public key and the time (or the blockheight) you want the fund to be locked until then. Send your fund to the generated address. Any fund sent to generated address will be spendable only after the lock time.
No, that's incorrect. Please read my previous answer.
You don't have to "make a move when the time is up" with CLTV/CSV. When the time is up, you (or the recipient of the payment) can spend the coins normally.
Of course you have to spend them, e.g. buying something or deposit the coins to an exchange. But in the case of Ethereum, you have to spend them too after they "unlock".
You may instead refer to an automatic payment after the unlock. But that was not what the OP requested afaik. It would also not make much sense: If you should be able to retract (spend to another address) before the locktime ends, then you can simply use nLocktime. If not (i.e. if your goal is that the funds will be paid without mattering what happens) then you can make either an upfront payment or use CLTV/CSV to avoid the recipient spends the coins before the lock.