Pages:
Author

Topic: How do timelocked transactions work? (Read 1190 times)

legendary
Activity: 2268
Merit: 18509
October 20, 2023, 01:27:10 AM
#47
Edit: I did that on my local time. Does it mean Coinbin uses the local timezone?
It uses unix time, which is what the bitcoin network uses as well to avoid issues with timezones, otherwise many nodes would incorrectly reject blocks from elsewhere in the world since their timestamps could differ by many hours.

Unix time is based on UTC time. Most block explorers will also show times based in UTC for this reason. Unix time is the number of seconds since 00:00 on 1st January 1970, UTC.

legendary
Activity: 2394
Merit: 5531
Self-proclaimed Genius
October 19, 2023, 11:23:45 PM
#46
Edit: I did that on my local time. Does it mean Coinbin uses the local timezone?
According to their source's javascript: "bootstrap-datetimepicker.min.js", the time picker uses "defaults={timeZone:"Etc/UTC",", AKA "UTC time zone".
Link to source: js/bootstrap-datetimepicker.min.js

Their service status page also uses the same timezone, link: https://status.coinb.in/
sr. member
Activity: 1820
Merit: 418
Need a campaign manager? | Telegram:@worldofcoinss
October 19, 2023, 04:38:47 PM
#45
It's not possible. I already tested this earlier in this thread here: https://bitcointalksearch.org/topic/m.62920786. Your transaction's timelock must have reached the exact block height or the exact network adjusted time to be accepted by a node.

You're correct. I tried broadcasting the transaction 1 hour before and it didn't work.

Edit: I did that on my local time. Does it mean Coinbin uses the local timezone?
legendary
Activity: 2268
Merit: 18509
October 19, 2023, 08:28:25 AM
#44
I tried to broadcast transactions before a valid date and got this error "the transaction was rejected by network rules. non-final"
This is the standard error for transactions with a timelock which has not yet expired.

I have set parameters today for hour 23:00, I'll try to broadcast the transaction around 21:10 and see if it's possible.
It's not possible. I already tested this earlier in this thread here: https://bitcointalksearch.org/topic/m.62920786. Your transaction's timelock must have reached the exact block height or the exact network adjusted time to be accepted by a node.
sr. member
Activity: 1820
Merit: 418
Need a campaign manager? | Telegram:@worldofcoinss
October 18, 2023, 07:43:19 PM
#43
It will be rejected by mempool,

I tried to broadcast transactions before a valid date and got this error "the transaction was rejected by network rules. non-final"
This error above was the same in both cases of Block height and Date and Time.

I read that you can broadcast it 2 hours before it becomes valid (but never tested this).

I have set parameters today for hour 23:00, I'll try to broadcast the transaction around 21:10 and see if it's possible.
legendary
Activity: 2380
Merit: 5213
September 29, 2023, 03:26:53 PM
#42
The other thing you mention is exactly what I wanted. I ll check it out.
If you want to use OP_CHECKLOCKTIMEVERIFY to lock output(s) of a transaction until a specified time/block height, you must create a timelocked address and that's what already discussed in this thread.
Take note that you can't send bitcoin to a regular address (a legacy or a bech32 address) and make the outputs locked until a specified time/block height.
sr. member
Activity: 406
Merit: 896
September 29, 2023, 03:01:41 PM
#41

Both of you refer to locktime. I was referring to OP_CHECKLOCKTIMEVERIFY. They are completely different.


Brilliant thanks! That's exactly what I was asking for. I now how lock time works. I've actually tested it and used it in real life for educational purposes. The other thing you mention is exactly what I wanted. I ll check it out.

legendary
Activity: 1512
Merit: 7340
Farewell, Leo
September 29, 2023, 02:56:46 PM
#40
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://bitcointalksearch.org/topic/m.22119
sr. member
Activity: 406
Merit: 896
September 29, 2023, 02:54:32 PM
#39
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
legendary
Activity: 2380
Merit: 5213
September 29, 2023, 02:51:54 PM
#38
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.
sr. member
Activity: 406
Merit: 896
September 29, 2023, 02:43:29 PM
#37
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?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
September 29, 2023, 02:27:52 PM
#36
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.
legendary
Activity: 2268
Merit: 18509
September 29, 2023, 01:10:27 PM
#35
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.
sr. member
Activity: 406
Merit: 896
September 29, 2023, 10:23:07 AM
#34
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?
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
September 29, 2023, 10:12:27 AM
#33
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.
sr. member
Activity: 406
Merit: 896
September 29, 2023, 09:56:58 AM
#32
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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
September 29, 2023, 09:47:17 AM
#31
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).

Quote
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.
sr. member
Activity: 406
Merit: 896
September 29, 2023, 09:26:08 AM
#30
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?
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
September 29, 2023, 06:53:47 AM
#29
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.
legendary
Activity: 2394
Merit: 5531
Self-proclaimed Genius
September 29, 2023, 02:47:08 AM
#28
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.
Pages:
Jump to: