I align more with the time-lock transaction which happens solely on the chain, but the defect I perceive is that if I set it for a long time, I could forget and still alive and the transaction will trigger.
In this case, you should make another timelocked transaction that will spend the same input to an output that you own with nLocktime set to an earlier date.
As you know it, once your transaction has been included to the blockchain, their version that has the same input will be invalid for spending an already-spent input.
It's up to you on how you will trigger an alarm on that date to either broadcast it or let your inheritors to broadcast their version of transaction on their expected date.
OP_CLTV is another alternative for that scenario because it has the necessary feature to allow your key to spend the locked output before the locktime and allow another key [
of the inheritor(s)] to spend it only after the locktime.
Example script:
IF
<Inheritor's Public key> CHECKSIGVERIFY
ELSE
<Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
ENDIF
<Your Private key's Public key pair> CHECKSIG
The problem is I'm not aware of any user-friendly implementation of that script in famous bitcoin wallets.
One option I can think of is to utilize Bitcoin Core's "
sh" or "
wsh" descriptor and "
miniscript" to import it to a watch-only wallet.
I've mentioned it since a third-party dead man's switch service that utilize this can be a good option since they will have no access to the funds until the locktime has passed. (
DYOR on your options)
Plus, you may get a backup private key or seed phrase and redeem script to potentially restore it in the future when it's easy to import such script.
You can keep multiple written backup of it on a safe/secret storage to keep your access to it secure.
But this doesn't solve the issue of the scenario when you forgotten about the locked bitcoins which IMO, can't be solved by any script.
In the other hand, the dead man’s switch could mess things up from the third-party side or if I lose access to the email, although it is more flexible because I can cancel it before execution date.
Yeah, that's the limitation of involving a third-party, their reliability and your access.
Just keep your backups of it secure in this case.