ELECTRUM wallet, error with LOCKTIME

[Chenipe]

I want to time-lock some Bitcoin for my newborn so he will have access to it when he turns 18.

When I use the locktime feature with the Electrum wallet, I always get this error message.

The server returned an error when broadcasting the transaction.
Consider trying to connect to a different server or updating Electrum.

non-final

I believe coins are available to be spent, I enter proper fees, etc.

Could someone please help me?

Thank you!

[nc50lc]

When I use the locktime feature with the Electrum wallet, I always get this error message.

The issue is: it isn't meant to be broadcasted until the set nLocktime has passed.

If you want to use that method, you'll have to save the signed raw transaction and keep the inputs of it unspent.
Then, the recipient can only broadcast it after the set locktime.
Of course, the recipient should still have access to the output's private key before deciding to broadcast the transaction.

Or are you perhaps pertaining to "Timelock Recovery Utility" plugin?

[Chenipe]

"If you want to use that method, you'll have to save the signed raw transaction and keep the inputs of it unspent."

I just gave it another try by using "locktime:raw" and then specified a future block, but I still get the same error message.

I'd really like to gift my newborn some sats and keep them unavailable for spending until a specific date. If you could point me the right direction to do that, that would be amazing.

[hosemary]

I just gave it another try by using "locktime:raw" and then specified a future block, but I still get the same error message.

As stated above by nc50lc, you can't broadcast a transactions with locktime into the furture.

I'd really like to gift my newborn some sats and keep them unavailable for spending until a specific date. If you could point me the right direction to do that, that would be amazing

The solution is to no longer keep the private key or the seed phrase of the sending wallet, keep the raw transaction and broadcast it in the future.

And you may want to consider creating a time locked address. Note that you should use this method only if you know what exactly you are doing.
For creating a time locked address, you can use the tool provided by coinb.in.

[LoyceV]

You should probably read Using Locktime for inheritance planning, backups or gifts. But: I wouldn't recommend making this your only backup for 18 years. There's already discussion about quantum computing, and we may see some protocol changes within the coming 18 years.
I've also seen someone lock his coins for more than a century, mistakes can hit hard with locktimes.

[nc50lc]

I'd really like to gift my newborn some sats and keep them unavailable for spending until a specific date. If you could point me the right direction to do that, that would be amazing.

There's OP_CLTV script that you can utilize but the wallets that support creating and spending from such script are limited.
And the process isn't as straightforward as P2PKH, P2WPKH and P2TR.
So I wouldn't recommend to users who aren't familiar with scripts.

For your intended solution (a simple transaction with nLocktime):
Create a paper wallet that is generated on an offline machine - so a private key and its derived address printed/written on paper.
Then, create a signed raw transaction with locktime that sends BTC to the above - so the signed raw transaction printed/written on that same paper.
And do not absolutely spend the input used in that transaction on another transaction so it wont be invalidated.

You may include instructions on how to redeem it like: "broadcast this transaction on xx-xx-2040 to receive <xx> BTC your <address>".
You can expand "broadcast" to step-by-step instructions if you prefer but it may not be applicable 1x years from now.

[pooya87]

I want to time-lock some Bitcoin for my newborn so he will have access to it when he turns 18.

Let me put it this way. Think about how Bitcoin works and what you are asking other nodes to do for you.

When you broadcast a transaction, you are giving it to other full nodes in the network and that tx remains in their system memory (mempool) until it is picked up by some miner and is included in a block.
When you are adding a locktime to your tx that prevents that tx from being mined for 18 years you are practically asking the nodes to store your tx for 18 years until it can be mined! That's an unreasonable request to have from other nodes, not to mention that if they start accepting such transactions, they can be spammed and run out of memory very quickly.

[LoyceV]

When you are adding a locktime to your tx that prevents that tx from being mined for 18 years you are practically asking the nodes to store your tx for 18 years until it can be mined! That's an unreasonable request to have from other nodes

This could be an interesting service to offer. Let's call it FutureTX: if the transaction pays a small amount to FutureTX's address, FutureTX has an incentive to keep that transaction for 18 years, and then broadcast it when it becomes valid. If you ever change your mind, all you need to do is spend the funds before the locktime, in which case FutureTX doesn't earn anything.
I'm not worried much about spam, those transactions don't take much disk space.

[stwenhao]

I'm not worried much about spam, those transactions don't take much disk space.

If it is just a few transactions, then maybe. But think about replaceability through full-RBF, and about free relay. I would recommend putting some Proof of Work protections, if someone wants to accept strange transactions with huge timelocks, extremely low or negative fees, or other uncommon use cases.

Also, as far as I know, there are some block explorers, which can accept timelocked transactions, for example: https://live.blockcypher.com/btc/pushtx/

However, even if they accept it, and show you, that it has 20% likelihood of being confirmed soon (which is false claim, but their estimators don't check locktime conditions), then still, after few hours or days, they will drop it (or when some higher fee transactions will come in).

[Abdussamad]

Quantum computers will make the current generation of bitcoin addresses obsolete within the next 5-10 years. So the funds you are trying to give your child will be stolen before they can ever be spent.

[pooya87]

I'm not worried much about spam, those transactions don't take much disk space.

The spamability is not about how much space each individual transaction takes, it is about how many of such transactions can be created by the spammer and the answer to that is virtually unlimited...

[nc50lc]

Quantum computers will make the current generation of bitcoin addresses obsolete within the next 5-10 years. So the funds you are trying to give your child will be stolen before they can ever be spent.

That's if the input of his timelocked transaction has its public key exposed.
Otherwise, it could still be safe.

But given that the intended locktime is 14 years, it's hard to conclude what will be the situation with QC and the current script types.
e.g.: It may be able to immediately steal just-broadcasted transactions from non-QC resistant scripts in 14 years / the script type used by OP could be consensus-invalid by that time, etc.