A doubt regarding Timelock feature | Bitcointalksearch.org

cygan

legendary

Activity: 3304

Merit: 8633

icarus-cards.eu

@so98nn if you are still looking for another solution... i would like to BTCump this topic up again
because in this matter there is now an update (this is first a beta version) which increases the default cltv delay from 40 blocks to 80 blocks. this increases the cltv delta value from ~7 hours to ~13 hours.

Quote

This change makes our default time locks more conservative which can help to avoid unnecessary force closures due to persistent mempool backlog, or node downtime.

https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta.rc2

nc50lc

legendary

Activity: 2618

Merit: 6452

Self-proclaimed Genius

Quote from: so98nn on August 04, 2020, 11:07:40 AM

My question is, can we relay the above transaction immediately? OR we have to wait for nLocktime to elapse due to the reason mentioned in first line?

The difference is "nLocktime" field is in the transaction as a parameter, even TXs w/ non-CLTV outputs have this.
In which the transaction itself can't be broadcast / will be rejected by nodes (as you post's first line said).
Think of it as a stand-alone feature for your question's sake.

So, if you set the nLocktime of the spending transaction at the future block/timestamp, you wont be able to broadcast it right away.

HCP

legendary

Activity: 2086

Merit: 4361

Quote from: so98nn on August 04, 2020, 11:07:40 AM

But when we lock UTXO with CHECKLOCKTIMEVERIFY, we have to set nLocktime of a transaction in which UTXO will be referenced as input greater than the CLTV locktime of the UTXO, right?

Correct, the nLocktime of the transaction that "spends" the CLTV UTXO must be greater than or equal to the original CLTV locktime.

Quote

My question is, can we relay the above transaction immediately?

No.

Quote

OR we have to wait for nLocktime to elapse due to the reason mentioned in first line?

Yes, as you have deduced, you must wait for the CLTV Locktime to have passed before the "spending" transaction will be considered as valid...

refer:

Quote from: https://en.bitcoin.it/wiki/Timelock#CheckLockTimeVerify

Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.

so98nn

hero member

Activity: 2114

Merit: 603

With nLocktime field, we can restrict transaction to be relayed or broadcasted after either 'n' number of blocks are mined or specific time has been elapsed. If we try to relay transaction before nLocktime has elapsed, transaction will be marked invalid and won't be broadcasted further by the first full-node which will receive the transaction, right?

But when we lock UTXO with CHECKLOCKTIMEVERIFY, we have to set nLocktime of a transaction in which UTXO will be referenced as input greater than the CLTV locktime of the UTXO, right?

My question is, can we relay the above transaction immediately? OR we have to wait for nLocktime to elapse due to the reason mentioned in first line?

Topic: A doubt regarding Timelock feature (Read 161 times)