How do timelocked transactions work?

[o_e_l_e_o]

The coins should be unlocked in the next couple of hours.

Did it work?

They had issues with coinb.in doesn't accept segWit Address. But, for me. It's accepted my segWit address.

It took many years for some services to start supporting segwit addresses. There are unfortunately some services (mainly some awful centralized exchanges) which still don't accept segwit addresses 5 years on!

Another thing is Some legendaries discouraged using this method in this thread; https://bitcointalk.org/index.php?topic=5214411.msg53504875#msg53504875

I generally dislike using web tools as well, but I am not aware of any reputable open source wallet which provides this feature, and for the vast majority of users manually crafting such a transaction is out of the question or incredibly risky, and so the web tool is the best option.

I would make sure to download and save a copy of Coinbin as well from their Github here (https://github.com/OutCast3k/coinbin/), just in case something happens to it before you need to spend your coins. Using your own copy offline will be easier than figuring out how to import your redeem script in to some other wallet software.

[1714239105]

1714239105

[1714239105]

1714239105

[Learn Bitcoin]

The coins should be unlocked in the next couple of hours.

Did it work?

Yay. There we go.
As I said, I was able to do what I needed to lock the wallet. I don't think I have to explain how I did it because you all know and you guys guided me on what to do. I have successfully unlocked my locked Bitcoin and sent it to my other wallet. Here is the last screenshot;



The last thing about this matter is. @o_e_l_e_o as I mentioned in my last post, Some members do not suggest this method. They suggested asking the wallet provider to develop this system and use this feature on a wallet. Do you think any wallet has such features?

I generally dislike using web tools as well, but I am not aware of any reputable open source wallet which provides this feature, and for the vast majority of users manually crafting such a transaction is out of the question or incredibly risky, and so the web tool is the best option.

I would make sure to download and save a copy of Coinbin as well from their Github here (https://github.com/OutCast3k/coinbin/), just in case something happens to it before you need to spend your coins. Using your own copy offline will be easier than figuring out how to import your redeem script in to some other wallet software.

Edit: I noticed you already posted. What timing? Thanks for the answer.
Yeah, I downloaded the offline version as well.
I guess I can continue now.

[worldofcoins]

I'm not a tech person, but what will happen if I lock my bitcoins for 10 years? and Coinbin website goes offline before that time, how will I be able to access my bitcoins at that time.

Didn't wanted to create a new topic so bumping up this one 

[LoyceV]

I'm not a tech person, but what will happen if I lock my bitcoins for 10 years? and Coinbin website goes offline before that time, how will I be able to access my bitcoins at that time.

Keep a backup copy of coinb.in Just like you should have a backup copy of Bitaddress.org and iancoleman.io.
You should use those sites offline and air-gapped anyway.

[o_e_l_e_o]

Even if coinb.in disappears and you don't have a copy, the addresses it creates follow a simple script in order to be timelocked. I explain the script in this post:

Let's take the following public key as an example, which is generated from the private key 0000....0001:

Code:

0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

Let's also say we don't want any coins on this address to be spendable until block 800,000.

So we head to https://coinb.in/#newTimeLocked and paste in our public key, select "blockheight", enter 800000, and hit "Submit". We then get shown a P2SH address which has the following redeem script:

Code:

0300350cb175210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac

Let's break that down:

03 - push 3 bytes to the stack
00350c - little endian encoding of the number 800,000
b1 - OP_CHECKLOCKTIMEVERIFY
75 - OP_DROP
21 - push 33 bytes to the stack

The next 33 bytes are the public key we pasted in as above, followed by 0xac, which is OP_CHECKSIG.

So this script essentially checks if we have reached the necessary block (or Unix time) specified. If we haven't, it terminates in an error. If we have reached the necessary height/time, then OP_CHECKLOCKTIMEVERIFY will verify, OP_DROP will clear the stack, and then all that is left will be the pubkey and OP_CHECKSIG as it would be in a old school P2PK output.

Given that, all you actually need to provide is a signature for the original private key and you will be able to sign transactions from this address, just as you would from an old school P2PK address. The rest of the script executes automatically.

[Synchronice]

How safe are timelocks? I mean, what if there is a radical change in bitcoin network that requires hard fork and what if everyone moves their nodes/miners to support the fork? I lack technical knowledge in this field so can anyone form a hypothesis what will happen if there is a hard fork that everyone follows? What will happen if there is a hard fork in 2026 but my coins are locked till 2028?

[LoyceV]

How safe are timelocks? I mean, what if there is a radical change in bitcoin network that requires hard fork and what if everyone moves their nodes/miners to support the fork? I lack technical knowledge in this field so can anyone form a hypothesis what will happen if there is a hard fork that everyone follows? What will happen if there is a hard fork in 2026 but my coins are locked till 2028?

With hard forks, all bets are off. If you picked a certain block in the future and we get 1 block per minute instead of every 10 minutes, it's going to be mined a lot faster.

[nc50lc]

I'm not a tech person, but what will happen if I lock my bitcoins for 10 years? and Coinbin website goes offline before that time, how will I be able to access my bitcoins at that time.

You'll just lose access to coinb.in's server that retrieves inputs for you through that "Load" button as well as its native broadcast, otherwise the offline version will still be functional.
While offline, it wont be able to preload the necessary data in the inputs and set the correct parameters of a valid OP_CLTV input.

Since you're not a tech person,
I'll just provide simple but detailed instructions on what data to add and change in coinb.in for your transaction to be valid while offline.

In "New->Transaction", "Inputs" tab:

• It's should point to the unspent transaction output that you want to spend.
  Both "Transaction ID:" and "N:" have a tooltip that briefly explains what it is by hovering over them.
  First is the "Transaction ID:" which is the TXID of the transaction that funded your timelocked address.
  Next, the "N" (output index) that starts with '0', if your address is the first output, it should be '0'; if it's second, it should be '1' and so on.
• The "Script" is the "Redeem Script" provided to you in "New->Time Locked Address" when you created the address.
• The "Amount" is the amount that you've received.

In "Outputs" tab:

• Just the recipient and amount.
  However, be careful on setting the amount since you wont be able to set the fee manually.
  The fee will be computed based from the input's amount and the output's amount, the fee rate will be computed manually from the final raw transaction's size so leave a reasonable amount for the fee.

Most importantly, expand the "Advanced Option":

• Under "locktime", the value should be edited from '0' to the value of the locktime that you've set or higher.
  If you've used the date and time format, you can decode your redeem script in Bitcoin Core via decodescript command to see its locktime; or use epoch converter.
  If left with default "0", the transaction will be rejected by nodes during broadcast by not following one of these conditions: BIP-0065.

Then proceed to 'Sign' and Broadcast the signed raw transaction to other push transaction services/clients.

[LoyceV]

On related note, aren't there anyone who archive Bitcoin-related software and source?

I've thought about it, but didn't want to be the one telling people "my copy is safe". Who's going to download Electrum from loyce.club? I still have a copy of a well-known paper wallet site that turned into a scam later, and I'm pretty sure my copy is still okay. But I can't know for sure, and people shouldn't trust me on it.

If it ever comes to it, I'm pretty sure many people have their own backups of coinb.in and other software, and as long as you keep it air-gapped and wipe the system afterwards, there's not much that can go wrong if you use someone else's old download.

[apogio]

Hey guys. I have asked this question again, but I can't find for some reason. I think it didn't have any answers anyway, so  I ask again.

Do you know if there is any way to create a timelocked transaction but broadcast it now and make it wait until the timelock? I am talking about an "automatic" addition to the mempool (somehow?) when the desired block has passed. I suppose it can't be done, because of the simple fact that there is nowhere that the nodes / miners could "save" this kind of transactions.

Wouldn't it be nice if there was such a feature? Do you think it would be bad for bitcoin to allow it? Or perhaps would it need radical changes to the way bitcoin works and therefore it can't be supported?

[LoyceV]

Do you know if there is any way to create a timelocked transaction but broadcast it now and make it wait until the timelock?

It will be rejected by mempool, I read that you can broadcast it 2 hours before it becomes valid (but never tested this).

I am talking about an "automatic" addition to the mempool (somehow?) when the desired block has passed. I suppose it can't be done, because of the simple fact that there is nowhere that the nodes / miners could "save" this kind of transactions.

Anyone with access to the transaction can broadcast it. There's no need to change the protocol for things that can be done already. See bitcoin-cli help sendrawtransaction. I'm running Bitcoin Core on a server, I could just try to broadcast your transaction every hour, or setup a scheduler that waits until it's time.
For more practical purposes, and I'm thinking of inheritance, you could just as well give the raw transaction to someone to broadcast when needed.

[apogio]

Anyone with access to the transaction can broadcast it. There's no need to change the protocol for things that can be done already. See bitcoin-cli help sendrawtransaction. I'm running Bitcoin Core on a server, I could just try to broadcast your transaction every hour, or setup a scheduler that waits until it's time.
For more practical purposes, and I'm thinking of inheritance, you could just as well give the raw transaction to someone to broadcast when needed.

Absolutely, I can also do that with my node, but automatic broadcast would mean that I wouldn't need to actually save the transaction anywhere. I guess I will have to implement it myself then.

[LoyceV]

Absolutely, I can also do that with my node, but automatic broadcast would mean that I wouldn't need to actually save the transaction anywhere. I guess I will have to implement it myself then.

If you're running a node anyway, you don't even need the locktime: you can just schedule the transaction. The locktime is a nice fail safe against mistakes though, and you can sign offline.

[apogio]

Absolutely, I can also do that with my node, but automatic broadcast would mean that I wouldn't need to actually save the transaction anywhere. I guess I will have to implement it myself then.

If you're running a node anyway, you don't even need the locktime: you can just schedule the transaction. The locktime is a nice fail safe against mistakes though, and you can sign offline.

I guess you mean writing a custom script, correct?

[o_e_l_e_o]

It will be rejected by mempool, I read that you can broadcast it 2 hours before it becomes valid (but never tested this).

I've not heard this before - I'm pretty sure it has to have reached the set time or the set block height, with no adjustments. Indeed, I just tried to broadcast a timelocked transaction on testnet, timelocked both 1 minute in front of my adjusted network time and also 1 block in front of the current block height, and both were rejected.

[BlackHatCoiner]

Do you know if there is any way to create a timelocked transaction but broadcast it now and make it wait until the timelock?

What you're really asking is if you can broadcast a transaction, have it mined, but lock its outputs until a specified time. This is "saving it temporarily", but "broadcasting it later". And there exists. It's called OP_CHECKLOCKTIMEVERIFY. Spending such locktime outputs before the specified nLockTime will cause the script to fail.

Wouldn't it be nice if there was such a feature? Do you think it would be bad for bitcoin to allow it?

The particular feature you mentioned would be bad, because it lacks the spam protection from OP_CHECKLOCKTIMEVERIFY. TX A is unconfirmed, you bloat the network with "not-yet-mineable" transactions. Before TX A becomes confirmed, you double-spend it with B and now all the other transactions are invalid.

You could also not depend on that feature. What if most nodes' mempools are clogged, and they only keep transactions paying an x sat/vb, which is higher than yours? The transaction will not be broadcasted at the time you'd have scheduled it.

[apogio]

Do you know if there is any way to create a timelocked transaction but broadcast it now and make it wait until the timelock?

What you're really asking is if you can broadcast a transaction, have it mined, but lock its outputs until a specified time. This is "saving it temporarily", but "broadcasting it later". And there exists. It's called OP_CHECKLOCKTIMEVERIFY. Spending such locktime outputs before the specified nLockTime will cause the script to fail.

Wouldn't it be nice if there was such a feature? Do you think it would be bad for bitcoin to allow it?

The particular feature you mentioned would be bad, because it lacks the spam protection from OP_CHECKLOCKTIMEVERIFY. TX A is unconfirmed, you bloat the network with "not-yet-mineable" transactions. Before TX A becomes confirmed, you double-spend it with B and now all the other transactions are invalid.

You could also not depend on that feature. What if most nodes' mempools are clogged, and they only keep transactions paying an x sat/vb, which is lower than yours? The transaction will not be broadcasted at the time you'd have scheduled it.

I get your point. Very good explanation. Thanks.

As far as the BIP that you mentioned is concerned, isn't it the definition of timelocked transactions? I mean are you sure that the only move I need to do is to broadcast it now and it will be mined in 2 years? Or do I need to do something else after those 2 years?

[hosseinimr93]

I mean are you sure that the only move I need to do is to broadcast it now and it will be mined in 2 years? Or do I need to do something else after those 2 years?

In the case you broadcast a transaction before its locktime, nodes will reject it and they won't keep your transaction in their mempool at all.
If the locktime of your transaction has been set to 2 years later, you have to wait for 2 years and then broadcast your transaction.

[apogio]

I mean are you sure that the only move I need to do is to broadcast it now and it will be mined in 2 years? Or do I need to do something else after those 2 years?

In the case you broadcast a transaction before its locktime, nodes will reject it and they won't keep your transaction in their mempool at all.
If the locktime of your transaction has been set to 2 years later, you have to wait for 2 years and then broadcast your transaction.

That's what I also know. But according to BlackHatCoiner and the BIP he mentioned, it may be possible to broadcast now, have it mined and locked until 2 years later

[BlackHatCoiner]

As far as the BIP that you mentioned is concerned, isn't it the definition of timelocked transactions?

Define me "timelocked". There's the "You cannot mine this until block x" timelocked (AKA, locktime). There's the "You cannot spend this until block x" timelocked. There's the "You cannot spend this after block x" timelocked*. All do lock to the future, though, yes.

I mean are you sure that the only move I need to do is to broadcast it now and it will be mined in 2 years?

No, it will be mined in 10 minutes, but the new UTXO cannot be spent until 2025.

In the case you broadcast a transaction before its locktime, nodes will reject it and they won't keep your transaction in their mempool at all.
If the locktime of your transaction has been set to 2 years later, you have to wait for 2 years and then broadcast your transaction.

That's what I also know. But according to BlackHatCoiner and the BIP he mentioned, it may be possible to broadcast now, have it mined and locked until 2 years later

Both of you refer to the locktime field. I was referring to OP_CHECKLOCKTIMEVERIFY. They are completely different. The former is checked when you attempt to include its transaction to a block. The latter is checked when you attempt to spend an output.


*This one doesn't really exist, but it exists in concept. It was called OP_BLOCKNUMBER, but the founder warned for security implications: https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119