A doubt regarding Timelock feature

[so98nn]

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?

[HCP]

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.

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

No.

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:

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.

[nc50lc]

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.

[cygan]

@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.

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