Bitcoin Forum

I have been looking for a way to lock a certain amount of BTC for certain days. Say for example, I want to lock 0.01 BTC for 100 days. Within this 100 days, no matter what I do, I will not have the access to the fund to spend. Only after that lock period, the 100 days, I will have the access to the fund to spend.
Is there any way to do this?
I know about Coinbase vault but I really don't want to go with them as they are centralized service.

The purpose is simple. I want to save this for someone. I may sometime in need of fund and will spend the BTC if I have access to the fund. That’s why I want to save a fund through such a way that I will not have access certain days and thus I will not have ways to spend.

what you are looking for is defined in BIP-65 with a new OP code called OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

you simply create an output script that includes a locktime and this OP code followed by the regular script that you use (eg. P2PKH) to have the CheckSig OP in it.
for example:

the script could also be used as the redeem script and used in P2SH or P2WSH output. in the later 2 cases the HASH160 is not needed and only the OP_CheckSig is required while the "signature" contains the sig + pubkey.

Would seem the OP does not want to use a centralized service:


Personally, I would just go with the nLocktime CheckLockTimeVerify solution. I'm not sure of any "mainstream" wallets that offer this service... but I know you can create a "Time Locked Address" on coinb.in fairly easily: https://coinb.in/#newTimeLocked

You just need to provide a public key (for a private key that you already hold) and a datetime... it'll automagically create the P2SH address and redeem script for you. You then simply send the funds you want to "lock" to the created address. Later, when you want to spend the funds after the timelock expires, you can simply provide the redeem script to coinb.in (and the private key necessary to sign) and you'll be able to create and broadcast the spending transaction.

Would probably be a good idea to create a standalone "throwaway" private key for this... to avoid having to use one from an existing wallet and the potential security issues with exposing private keys from HD wallets etc.

Maybe prepare/configure a hardware wallet and deposit at notary?

This is not simple for people like me that don't have any background on programming. Even though all code was written. It will need a step by step guide on how to do it like open a note and etc. A video tutorial will be very helpful to easily follow this guide. I will be happy to learn how to this since I need this feature too for saving my money that I earn here. Actually, creating a tutorial thread for this topic is very helpful pooya.  :D

Is this guide requires fee?

That's correct. And I think that the easy solution is to use Timelock feature in Electrum, which is available on the advanced tab at/"after" sending.
The initial purpose is slightly different, but this thread shows how to use Timelock in Electrum: [Tutorial] Making your crypto inheritible (https://bitcointalk.org/index.php?topic=5285003.0)

PS. Obviously I recommend trying it out for free on Testnet  ;)

I doubt OP wants to do this since this also is a centralized approach.




There are tutorials and guides available here on this forum and the world wide web. You just need to search for them.


@OP
OP_CHECKLOCKTIMEVERIFY seems to be your best bet here.
But be assured that there is no way to access / send your coins before the specified date. If you lock them for 100 days, they are locked for 100 days. There is no way around it.

unfortunately i don't know of any wallet that allows working with scripts or has pre-defined ones like OP_CLTV. there are some "tools" that have this capability and if run offline from their source code they could be useful. although lack of popularity could mean possible bugs which you have to keep in mind when using them.
one tool was already mentioned (https://coinb.in/#newTimeLocked) and here is a link explaining the steps: https://bitcointalk.org/index.php?topic=2415595.msg24712087#msg24712087
for more information on timelocks you can check out bitcoin book: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc#timelocks

sorry i can't make video tutorials but feel free to ask any questions you have here.

nLocktime is the last 4 bytes of all the transactions. what you meant was the lock time OP codes. but this gave me an idea for an easier method of locking funds which may be a little silly but it could work.

if you already have the funds (control the private key of the output) you can create a new transaction and send the coins to a new address from a new wallet but set the nLocktime of the transaction to a future value (like 100 days). you obviously can't broadcast this transaction because it will be rejected but you can create a backup of it. write it down on a piece of paper, put it on the internet,... then destroy the private key of the output you are spending. that means you can't double spend this output and have to wait 100 days until you can broadcast this tx and have it mined to have access to the new output in the new address from the new wallet you create in the beginning.
the problem with this method would be fees which you can't predict how much they will be in the future and you may over/under-pay.

It's weird no one mention Bitcoin Core command createrawtransaction, which have option to set locktime. Here's output of help createrawtransaction


It's mostly manual (select input TXID, input output number, etc.), but at least you don't need to deal with creating script manually.


You need to create a transaction where the output contains custom script, so technically it requires fee (transaction fee).

Agreed and I already search on world wide web, I have trust issue on using online tutorial out that's why I want to know a method directly from the person I trust(In this case pooya). There still no step by step tutorial using the code he mention which I find much safer to use if I do it correctly compared on using 3rd party service provider.

Anyway coinb.in is the simplest way to this coin timelock.

EDIT:

Just read the post above. Thanks ETFBitcoin.

It seems like you are referring to create a tx which will be released at certain date, isn’t it? If so, will I be able to use the same input once I decide to spend them before the lock time? And that's not exactly my purpose.
I'm yet to figure out all the process as I'm not much techy guy but I'm trying to figure out the process and will do soon.

Actually it should exactly be what you are looking for.

The locktime sets the date (block height) from which the output can be spent.
The process would be that you'll generate a transaction containing the locktime to an address you have the private key of with a locktime of roughly X days and broadcast it.
After the transaction has been included into a block, you'll only be able to spend that new output (to the new address) after the locktime is over.

This sounds good. I'm exactly looking for this. I thought the tx itself will be locked. If the fund sent to the address can't be spent, then that’s what I'm looking for. I actually misread above posts and mixed it with something I mentioned (the tx lock). Thanks a lot. No merit to spend.

But unfortunately, that's not how it works... if you specify "nLockTime" in a transaction, it means that the transaction is not able to be included in a block until AFTER that time period has passed. It's like "post dating" a cheque... it can't be cashed until at least the date printed on the cheque.

If you set the locktime for a transaction to be in 100 days, no miner will be able to include that transaction in a block for 100 days... and a lot of nodes won't even propagate the transaction as they will not consider it "final"... this is the error code I get when trying to broadcast a transaction before the LockTime:

Even if you have a transaction that is locked, you could quite easily just create another transaction that spends those same funds, that has no locktime and can be broadcast/confirmed immediately.

To prevent spending, the OP_CHECKLOCKTIMEVERIFY option (aka OP_HODL) is the answer. I have been experimenting with the "Time Locked Address" functionality on coinb.in (via TestNet) and it works as advertised. The only caveat being that you will need to use coinb.in in the future to generate and sign the spending transaction, as I don't seem to be able to get it working properly with Bitcoin Core (but that might be something I'm doing wrong)

---

---

NOTE: for the purposes of this tutorial, I have used a TestNet address and that the coinb.in code requires some tweaking to automatically retrieve the UTXOs for TestNet addresses (https://github.com/OutCast3k/coinbin/pull/196/files).


Step 1 - Get a private key
- You want this in WIF format.
- You can use one from an existing wallet, but be warned, you will need to put this into coinb.in to be able to sign the spending transaction later.

Example (TestNet) PrivKey in WIF format:
cQxRyfN5wBmDAc4tX1kP2bDZ5A3woXsayc1VLXu74WVc7ukmqQb6


Step 2 - Get the public key that matches your private key
- you need the hex public key, NOT the address

Example Hex Pubkey matching PrivKey:
032371229be41fd3d89d5dddd02cdfbcafbea07ec25ff2e8d9db1c8cd5983361bc


Step 3 - Create the "Time Locked Address":
- You can do this here: https://coinb.in/#newTimeLocked
- Alternatively, you can download the coinb.in code base and run it offline
- Enter the hex public key from Step 2, and pick the date/time you want the address to be locked to.
- Click "Submit"
https://talkimg.com/images/2023/11/15/zvf5f.png


Step 4 - Note down the "Time Locked Address" and "Redeem Script":
https://talkimg.com/images/2023/11/15/zvJUZ.png

Example TLA:
2NAkEGEghkTs5BGn9kgK2PbMhaE2gThPgA3

Example Redeem Script:
04e056a55fb17521032371229be41fd3d89d5dddd02cdfbcafbea07ec25ff2e8d9db1c8cd598336 1bcac


Step 5 - Send funds to the "Time Locked Address"
- This is just a "standard" transaction
- Send using whatever wallet/fee etc. that you find appropriate.
https://talkimg.com/images/2023/11/15/zvVR8.png

Example Funding Transaction:
64ad87ac7789eae5190b8e76570ca6ad350ffccf1a5f59af0ae774dbde190a25 (https://blockstream.info/testnet/tx/64ad87ac7789eae5190b8e76570ca6ad350ffccf1a5f59af0ae774dbde190a25)


Step 6 (Optional) - Try and send "locked" funds

6.a: - Load "Inputs":
- Visit https://coinb.in/#newTransaction (or use your downloaded, offline version)
- Enter redeem script and click "Load" (won't work with "offline" mode)
- Click the "Inputs" tab
- You should get the UTXO(s) in your locked address loaded:
https://talkimg.com/images/2023/11/15/zvj13.png

6.b: - Create "Outputs":
- Click on the "outputs" tab
- Enter the receive address and amount you want to send (IMPORTANT NOTE: any amount you don't specify in outputs, will be used as the TOTAL fee!!)
https://talkimg.com/images/2023/11/15/zvrew.png

You can see I specified an output of 0.01999700... the difference between that and the total input (0.02) is going to be used as the total fee amount (0.00000300)... Unfortunately, there isn't a way to specify a fee rate, you need to work it out yourself... these "Legacy" transactions end up being around ~200 bytes... so my total fee of 300, ends up being around 1.5 sats/byte. Pretty low, but testnet is forgiving like that ;)

6.c: - Get unsigned transaction:
- Once you're happy with the outputs and fee, click Submit:
https://talkimg.com/images/2023/11/15/zvLQ9.png

Example raw unsigned transaction:

6.d (Optional, but recommended): - Verify your transaction:
- https://coinb.in/#verify
- Enter your unsigned transaction and click submit
https://talkimg.com/images/2023/11/15/zvcfN.png

Double check that everything is in order

6.e - Sign the transaction:
- Enter the unsigned transaction
- Enter the private key from Step #1
- Click Submit
https://talkimg.com/images/2023/11/15/zvhKa.png

As per the note, make sure to double check that your fee rate is going to be OK... in this example... size = 200, fee was 300... 300/200 = 1.5 sats/byte. If you screwed up the fee rate, you can simply go back and start Step 6 again, and use a higher fee... the transaction should end up being about the same size (maybe 1 or 2 bytes in either direction), so you should be able to calculate it easily the 2nd time round ;)


6.f - (Try) Broadcast the transaction:
- I tried to broadcast before locktime using the BlockStream Explorer (https://blockstream.info/testnet/tx/push):
https://talkimg.com/images/2023/11/15/zv4Ao.png

https://talkimg.com/images/2023/11/15/zv5IT.png

and using Bitcoin Core:
https://talkimg.com/images/2023/11/15/zv75l.png

Congrats... your funds are now LOCKED! :)


Step 7 - Broadcast once the timelock has expired:
- Now we just repeat Step 6 again, but broadcast AFTER the locktime has passed, and we can see that the transaction was a success:
https://talkimg.com/images/2023/11/15/zvBU1.png
2972b09a1f0f52d8810368acc894cc6b2af6a1a7ae23e73d89aec68ddf6dd8ae (https://blockstream.info/testnet/tx/2972b09a1f0f52d8810368acc894cc6b2af6a1a7ae23e73d89aec68ddf6dd8ae)

https://talkimg.com/images/2023/11/15/zvgTm.png

---

That is indeed what I meant... I just typed the wrong thing... this is what happens when you try to be clever after midnight! :P ::)

I've edited my post to reflect that.

I do not see the problem, CPFP will be cheaper than a p2sh-transaction.

I wrote this last year: Using Locktime for inheritance planning, backups or gifts (https://bitcointalk.org/index.php?topic=5180850.0). It's important to know the Risks before doing this. I suggest to try with a small amount before funding a lot.

CPFP has to create a new transaction spending the unconfirmed one and pay for its own fee plus any extra fee that is needed to get the unconfirmed one bumped to high priority. that will always be more expensive than just paying higher fee in the unconfirmed tx.

I was sure that this p2sh-transaction would definitely be larger than 220 bytes (220 vbytes take up two P2WPKH-transactions). But I was wrong, it only takes 200 bytes. So at worst, it will be 10% more expensive. Although sometimes it will still be cheaper because there are always two transactions in the cltv-scheme rather than one.

We're you able to do it successfully and redeem without problems?

The one that is being discussed here and the one I am about to write below, are these one and the same locking processes for the transactions/bitcoin in the wallet? I mean what is being asked in OP reads out as, I have bitcoins in my wallet which I should be able to lock and I can’t just spend them in any way possible.

However, checkout this article here Locktime Field in a Transaction used for Post-dating.  (https://learnmeabitcoin.com/technical/locktime#:~:text=You%20can%20use%20locktime%20to,or%20a%20point%20in%20time.&text=Unlocked%20at%20block%20height.&text=If%20you%20do%20not%20want,block%20height%20or%20unix%20time).)

So just would like to know that whatever explained in the article linked above is related to transactions that we do which can be locked until specific block is mined. I think this is one of the way to do it? We can always send the transaction to our own address and use the method mentioned in the article thus locking it for specified time period.

No, they are not the same. What you have linked as explanation on learnmeabitcoin.com is a transaction with a locktime in the future. If it is already signed you can only broadcast it when the locktime has elapsed. If you try to broadcast it before the locktime is elapsed, every receiving node will reject and drop your transaction. It can't and won't be mined into a block because that would make the block invalid if it contains a transaction with a locktime still in the future.
If you're the only holder of such a signed transaction, you could delete the transaction and create a new one. The Bitcoin network obviously doesn't know about your locktime-transaction as you can't broadcast it upfront.

What is described in this thread is a P2SH transaction that has a redeem script that can only be fulfilled when the locktime in the redeem script has elapsed. Before that, any attempt to transfer funds locked by such a redeem script will fail. All funds locked by such an address are truely locked until the script's locktime has elapsed. You can't do anything about it, unless you change the code of every participating node in the Bitcoin network (not gonna happen).

Public addresses are nothing more than recipes how to redeem funds which "have been sent to" such addresses. The expression "sent to a public address" is technically incorrect. What you express by that is to specify a certain type of redeem script and how to fulfill it to be able to move the locked coins by that redeem script. The Bitcoin blockchain itself doesn't know anything about public addresses, nor does it contain them.

A time-locked redeem script gives a P2SH address of the form 3..., the hash of the redeem script is the public address.

There was recently a thread where someone sent a substantial amount of Bitcoin to a P2SH address where the redeem script can only be fulfilled in 125 years (likely due to a 0 digit too much when the redeem script was constructed). Well, shit happens...

I am afraid now, what if i sent a locked Bitcoins in the future by accident? Can anyone tell me what to be careful from so i can prevent it by happening? I mainly use Bitcoin Core for sending and receiving Bitcoins.

Thanks,

GR

Bitcoin Core allows the user to specify an nLockTime for their transaction which is basically a guarantee that the transaction cannot be included in a block before the block has elapsed. This doesn't lock your coins in any form, and most of it has to do with how your wallet perceives the "spendable" coins. Deleting that transaction or otherwise spending the coins would still be possible.

If you're talking about an nLockTime address (aka. OP_HODL), it has to be created and scripted manually. So long as it is a P2SH address, it won't contain any nLockTime locks and it has to be pretty deliberate.