nlocktime as a service practical use case scenarios

[WhyFhy]

I want to mess with the idea of this , some people aren't technically inclined enough to know how to do this or that it can be done. So I see an opportunity to potentially educate curious onlookers and provide a BTC fwd timelock service.

I kinda already know how to go about doing this my question is why would you use a service like this? Is there even a real use case?

Service idea is simple
Deposit savings amount , handler  takes 1% and deposits the rest to desired wallet with attached nlock.

They say this service is not recommend for long durations of time due to potential blockchain changes possibly locking you out of your BTC forever.

[NotATether]

It makes no sense as a business model (or even as a free service). Also it is potentially not secure because you can't add an nlocktime after the transaction is signed. And if people give you their transaction params then you can't add locktime and sign them without their private keys, which you don't have.

What I would like to see is a feature in wallets that let you lock the transaction until <n> blocks pass (and set a maximum n of about 100 or something to prevent extraordinarily long lock times), so nlocktime: height+n.

[vjudeu]

you can't add an nlocktime after the transaction is signed

Yes, you cannot change the locktime for the whole transaction. But if you use OP_CHECKLOCKTIMEVERIFY instead, you can place your locktime as your input instead of doing that as your output. Of course if you allow putting any value here, it will be unsafe, because then anyone could set any time, but if you protect it with something like OP_CHECKSIG (or some kind of multisig), then you can decide who can set that locktime after transaction creation. For example, "OP_CHECKLOCKTIMEVERIFY <AlicePubKey> OP_CHECKSIG" will allow setting locktime by Alice, she can put "<signature> <locktime>" as her input and produce different signatures with different locktimes in the future, that will not affect signatures created by other people, as long as the whole unsigned transaction remains unchanged.

What I would like to see is a feature in wallets that let you lock the transaction until <n> blocks pass (and set a maximum n of about 100 or something to prevent extraordinarily long lock times), so nlocktime: height+n.

You can lock your transaction to some future block number, so I don't understand what else do you need, if you know the latest block number, you can do that addition by yourself. It is unknown when exactly the whole transaction was created, so there is nothing like "now+100 blocks", because only transaction creator knows what was the latest block number at that time. Also, there is OP_CHECKSEQUENCEVERIFY where you can create relative locktime, so you can replace 100 blocks with "1000 minutes from now".

Also note that we have OP_ADD in the Script, so you can lock your coins to "<current_height> 100 OP_ADD OP_CHECKLOCKTIMEVERIFY", it is even possible to protect those numbers with some kind of OP_CHECKSIG, so you can decide who can provide the current height and who can decide how many blocks from now that transaction will be unlocked.

[garlonicon]

What I would like to see is a feature in wallets that let you lock the transaction until <n> blocks pass (and set a maximum n of about 100 or something to prevent extraordinarily long lock times), so nlocktime: height+n.

We already have transactions that are locked for 100 blocks, they are called coinbase transactions. So you can swap your coins with some miner in a provably fair way (for example by using CoinJoin), then you can make a transaction that will be valid after 100 blocks. If you need less value, you can simply use some coinbase that has some confirmations, for example you can create a transaction that is timelocked for 90 blocks if you use some coinbase with 10 confirmations.

[Quickseller]

I don't understand the potential benefit to the end user. If someone doesn't want to spend their own bitcoin, they can simply not broadcast a valid transaction spending their bitcoin. nLockTime is a means to allow a transaction to be prevented from confirming in the event of some kind of dispute between parties conducting business, so the other party can broadcast a conflicting transaction in the interim.

[ABCbits]

If you bother use Bitcoin OPCODES, why don't you just create software with good UI/UX or add such feature to existing open-source wallet (such as Electrum)? Wallet such as Electrum already support custom script (such as OP_RETURN), so we just need someone to make it more user-friendly.

Service idea is simple
Deposit savings amount , handler  takes 1% and deposits the rest to desired wallet with attached nlock.

If i'm going to use 3rd party to lock my Bitcoin, i would rather use service such as BlockFi which give me some interest rather than losing 1% of my coin.

[WhyFhy]

If you bother use Bitcoin OPCODES, why don't you just create software with good UI/UX or add such feature to existing open-source wallet (such as Electrum)? Wallet such as Electrum already support custom script (such as OP_RETURN), so we just need someone to make it more user-friendly.

Service idea is simple
Deposit savings amount , handler  takes 1% and deposits the rest to desired wallet with attached nlock.

If i'm going to use 3rd party to lock my Bitcoin, i would rather use service such as BlockFi which give me some interest rather than losing 1% of my coin.

I was going to go off core or electrum and that was sorta the goal just make it easier for people I did a vanity handler for VS but it's got issues, non vanity outputs is the biggest problem and emails and authorized apps (building off Google sheets/forms to keep a security gap , I'm just wanting to toy with it I've been messing with handlers and automation for about a year now and just want to keep some motion going. )

I wholly agree with the blockfi statement but this could be cool for weird niche needs like betting, gifts, on chain style timed escrow to maintain internal service contracts things of that nature

I'm just looking for a project within my scope but I don't wanna mess with stuff nobody will use.  This seems like a bad project idea so far based on the feedback. But it sounds fun!(to me)

I would love to timelock like $100 for 10 years till my kiddo graduates (hand my kid a cool paper wallet or something like that tell em it's worthless untill 2031) but I'm nervous about network changes.  I'm pretty certain any and all changes with have workarounds with timelock in mind but who knows.

[aliashraf]

Service idea is simple
Deposit savings amount , handler  takes 1% and deposits the rest to desired wallet with attached nlock.

They say this service is not recommend for long durations of time due to potential blockchain changes possibly locking you out of your BTC forever.

There is no possibility for coins to be locked out because it is part of the consensus. It is not recommended, having large lock time in transaction level by using nLockTime field, as not only Miners are prohibited from including the transaction in the blockchain by consensus rules, nodes do not keep track of it, even broadcast it, once they are implemented conveniently, so, it would be either the creator or the receiver's responsibility to keep the source of the txn safe and secure until it matures, an annoying situation.

Transaction level lock time is a very important feature and one of the smartest ones in Bitcoin, with interesting use cases which otherwise are very hard if not impossible to provide, e.g:

A simple digital will
You could pass your coins to your heir(s) by locking them in a transaction which distributes your balance between them according to your wish, giving copies to your lawyer and/or heir(s). As the transaction nLockTime field is set to like a year later, nobody could relay it to the network and if hopefully you are not passed away, before the lock time arrives you can spend the inputs by a normal transaction and renew the process forthe  next year and so on.

A proof of commitment and affordability
To show her commitment and financial strength to her contractor, Bob, Alice pays some coins to him with a time lock set for a while after the project's dead time. In this scenario, keeping an eye on the blockchain, Bob remains confident enough that if everything goes well there is some money for his compensation and Alice is serious about her order. Meanwhile, Alice has absolute power to make the transaction void by spending at least one of the inputs, which sends a signal to Bob to react properly.

 
For OP_CHECKLOCKTIMEVERIFY, we are dealing with a totally different feature with its own use cases (most importantly HTLC), it is definitively not an alternative to nLockTime, as here the coins are moved permanently, and it is just a matter of time for the receiver(s) to have access.

[garlonicon]

it is definitively not an alternative to nLockTime, as here the coins are moved permanently, and it is just a matter of time for the receiver(s) to have access

Why not? You can use OP_IF and require Alice's signature with OP_CHECKLOCKTIMEVERIFY or Bob's signature with different locktime or even no locktime. It is equivalent to creating two transactions with different locktimes, where Bob's transaction is valid instantly (or earlier) and both transactions are valid after some time. Using separate transactions to achieve that is now cheaper, but with Taproot they can be equally expensive if you have two sibling tapscript branches (or it could be cheaper than now when spending by key instead of spending by tapscript).

[aliashraf]

it is definitively not an alternative to nLockTime, as here the coins are moved permanently, and it is just a matter of time for the receiver(s) to have access

Why not? You can use OP_IF and require Alice's signature with OP_CHECKLOCKTIMEVERIFY or Bob's signature with different locktime or even no locktime. It is equivalent to creating two transactions with different locktimes, where Bob's transaction is valid instantly (or earlier) and both transactions are valid after some time. Using separate transactions to achieve that is now cheaper, but with Taproot they can be equally expensive if you have two sibling tapscript branches (or it could be cheaper than now when spending by key instead of spending by tapscript).

You are right, it is feasible to mimic nLockTime functionality somehow using OP_CHECKLOCKTIMEVERIFY while taproot could help to reduce the cost (the point I missed considering), but the fact that we need multiple txns, all residing in the blockchain, should be noted. In the "digital will" use case, it results in an "annual fee" cost, for instance.

The off-line nature of nLockTime puts it in a place basically different from the latter.