The dead man’s time lock

[MarryWithBTC]

I am hodling BTC, I will marry this year. I have studied two different bitcoin inheritance model (The Time-locked bitcoin transaction and The Dead Man’s Switch). 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 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.
Is there a model or a solution that can treat my fears by giving me a fair balance?

[nc50lc]

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:

Code:

     IF
        <Your Private key's Public key pair> CHECKSIG
    ELSE
        <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
        <Inheritor's Public key> CHECKSIG
    ENDIF

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.

[pooya87]

Example script:

Code:

     IF
        <Your Private key's Public key pair> CHECKSIGVERIFY
    ELSE
        <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
    ENDIF
     <Inheritor's Public key> CHECKSIG

In this script the inheritor is always one of the signers when you want to spend those coins meaning the original owner will not be able to move their coin without the second signer.

If that's the intention it can be simplified like this using multisig (2 sigop count)

Code:

IF
  2
ELSE
  <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
  1
ENDIF
<Your Private key's Public key pair>
<Inheritor's Public key>
2
CHECMULTIKSIG

Or can be fixed by pulling the inheritor's pubkey into the else branch (1 less sigop count).

Code:

IF
  <Your Private key's Public key pair>
ELSE
  <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
  <Inheritor's Public key> 
ENDIF
CHECKSIG

[MarryWithBTC]

Example script:

Code:

     IF
        <Your Private key's Public key pair> CHECKSIGVERIFY
    ELSE
        <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
    ENDIF
     <Inheritor's Public key> CHECKSIG

In this script the inheritor is always one of the signers when you want to spend those coins meaning the original owner will not be able to move their coin without the second signer.

If that's the intention it can be simplified like this using multisig (2 sigop count)

The intention is to keep the beneficiary unaware for security purposes.

[nc50lc]

The intention is to keep the beneficiary unaware for security purposes.

In that case, you don't have any choice but to rely on a third-party.

Firstly, a timelocked transaction isn't something that can be broadcasted now, then executed later. It'll be rejected by nodes if the locktime hasn't passed yet.
Its use-case is: it has to be given to the beneficiary or a third-party that will broadcast it at the specified time/block height.

Secondly, a timelocked output script like the examples will not be spent automatically, it has to be spent by the beneficiary himself or a third-party to send the bitcoins to the beneficiary's wallet.

Lastly, given that it has to be kept secret to the beneficiary, the third-party has to keep the necessary information to broadcast or spend instead.

In this script the inheritor is always one of the signers when you want to spend those coins meaning the original owner will not be able to move their coin without the second signer.

Thanks, I've edited the script to match the intent.

[odolvlobo]

Inheritance is a legal issue, so I suggest contacting an estate lawyer who is familiar with Bitcoin. Also, there are companies, such as Casa (https://casa.io/inheritance), that provide these kinds of services.

[apogio]

Lastly, given that it has to be kept secret to the beneficiary, the third-party has to keep the necessary information to broadcast or spend instead.

Which in my opinion creates a greater security issue, because normally, the beneficiary is someone we know. Therefore, if we have to give a time-locked transaction to someone, trusting that they will indeed broadcast it when the time comes, wouldn't it be better to rely on our beneficiary instead of an intermediary? This is purely subjective, I am just expressing my thoughts. And lastly, a time-locked transaction will send coins to an address. How would we make sure that the beneficiary owns the private key to unlock the coins at that address?

What I want to say is, in general, wouldn't it be better if we let our beneficiary now about our intentions and plans?

[nc50lc]

What I want to say is, in general, wouldn't it be better if we let our beneficiary now about our intentions and plans?

This is normally the case which is where those two example use-cases can be applied...

But,

Which in my opinion creates a greater security issue, because normally, the beneficiary is someone we know. Therefore, if we have to give a time-locked transaction to someone, trusting that they will indeed broadcast it when the time comes, wouldn't it be better to rely on our beneficiary instead of an intermediary?

I think OP is concerned of his personal security.
Where the beneficiary and his/her relatives may threaten him (physically) once the knowledge of him owning bitcoins is disclosed.

[apogio]

But,
I think OP is concerned of his personal security.
Where the beneficiary and his/her relatives may threaten him (physically) once the knowledge of him owning bitcoins is disclosed.

Oh you mean that OP wants to pass some coins to some beneficiaries, but is worried that he may be threatened by them?
Well, it's a personal situation so let's not go deeper. But, it makes me curious because if someone wanted to give me bitcoins, I wouldn't threaten them.

[ABCbits]

Lastly, given that it has to be kept secret to the beneficiary, the third-party has to keep the necessary information to broadcast or spend instead.

If OP willing to take the risk, he could store such information on place where he lives. But the risk is either nobody could find it or someone find it before expected time/condition.

Inheritance is a legal issue, so I suggest contacting an estate lawyer who is familiar with Bitcoin. Also, there are companies, such as Casa (https://casa.io/inheritance), that provide these kinds of services.

FWIW, https://thebitcoinhole.com/inheritance show list of such Bitcoin inheritance service/software.

[LoyceV]

Oh you mean that OP wants to pass some coins to some beneficiaries, but is worried that he may be threatened by them?

Let's be realistic here: if enough people create a timelock that makes someone rich ones the time expires, some of them are going to get killed.

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.

Just write it in your agenda: even if you use a paper agenda, at the end of 2025 you write: "timelock expires 2034", and each year you write that in your new agenda. That gives you many years to move your coins and create a new timelock.

[apogio]

Bitcoin has many attributes that gold has. There are also significant differences but let’s focus on inheritance, since this is the topics subject.
How do people traditionally pass gold to their inheritors? What’s the process? I imagine that the same process to give your beneficiaries a golden bar would apply to giving them a seed phrase.
After one has passed away, it’s similarly difficult to let your beneficiaries know about the location of the gold bar and the location of the seed phrase. Isn’t it?

[LoyceV]

How do people traditionally pass gold to their inheritors?

My guess: under the table

What’s the process?

I honestly don't know. Most people don't own gold bars, and most assets (real estate, vehicles, investments, bank accounts) are registered in their name so a notary can handle the inheritance. The fact that most of it is registered in your name makes it much harder to commit fraud.

I imagine that the same process to give your beneficiaries a golden bar would apply to giving them a seed phrase.
After one has passed away, it’s similarly difficult to let your beneficiaries know about the location of the gold bar and the location of the seed phrase. Isn’t it?

Here, you'd have to pay taxes on the gold bar you inherit, so there's paperwork involved.

[apogio]

I honestly don't know. Most people don't own gold bars, and most assets (real estate, vehicles, investments, bank accounts) are registered in their name so a notary can handle the inheritance. The fact that most of it is registered in your name makes it much harder to commit fraud.

Ok forget the gold bars and let’s talk about jewellery. I believe a great number of people own jewellery and they pass it to their children as inheritance. Don’t they?
I know most people keep it at home because jewellery is supposed to be worn for cosmetics, whereas the gold bars don’t offer anything apart from exposure to gold.

[LoyceV]

Ok forget the gold bars and let’s talk about jewellery. I believe a great number of people own jewellery and they pass it to their children as inheritance. Don’t they?

I'm not much into jewellery myself, but I'd expect most people to have not too much value. The value will be mainly sentimental.

To me, Bitcoin inheritance gives the same uneasy feeling as storing seed phrases: there is no perfect solution, so it's always a compromise.

[apogio]

To me, Bitcoin inheritance gives the same uneasy feeling as storing seed phrases: there is no perfect solution, so it's always a compromise.

It’s because if someone steals the seed phrase, you are screwed. There is not a good way to encrypt the offline backup, while also making it durable.

For cold storage of money where I don’t need to spend soon, I would opt for BIP38 because it gives me the peace of mind that the backup is safe even if someone finds it. At the same moment it’s very easy for someone to understand how it works. Simply scan a QR code, add the password and you are good.

But for storage where you want to spend often, it’s a whole other story.

Anyways let’s not derail the conversation.

I agree with you in that Bitcoin inheritance isn’t easy to do and causes over-thinking

[philipma1957]

But,
I think OP is concerned of his personal security.
Where the beneficiary and his/her relatives may threaten him (physically) once the knowledge of him owning bitcoins is disclosed.

Oh you mean that OP wants to pass some coins to some beneficiaries, but is worried that he may be threatened by them?
Well, it's a personal situation so let's not go deeper. But, it makes me curious because if someone wanted to give me bitcoins, I wouldn't threaten them.

well suppose it is 50 coins. The person due the coins may want it now for fear of a true death spiral. 🌀

If you told me you had a lawyer holding a trezor with 50 coins in it waiting for you to die so the lawyer would hand the trezor to me.

I likely would want some of the coins now just in case of a price collapse.

[NotATether]

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:

Code:

     IF
        <Your Private key's Public key pair> CHECKSIG
    ELSE
        <Your Preferred inheritance date> CHECKLOCKTIMEVERIFY DROP
        <Inheritor's Public key> CHECKSIG
    ENDIF

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.

Touching descriptors and scripts to make a DIY dead man's switch is really dangerous if you don't know what you're doing. It can cause a total loss of funds in dramatic Wile E. Coyote fashion.

I'm not saying that to scare anyone, but it is much better to simply use a third party guarrantor/trustee. I wouldn't even trust random companies for something this sensitive. Not because they might steal the funds but because they might screw something up.

[nc50lc]

-snip-

Touching descriptors and scripts to make a DIY dead man's switch is really dangerous if you don't know what you're doing. It can cause a total loss of funds in dramatic Wile E. Coyote fashion.

Yes, this is why it's recommended to test the setup before actually using it.
That's all I can add because I've already included the issue of that setup in that quoted message.

Perhaps, it'll more viable the future when clients/wallets make it easy to import or create such script.
For now, the closest is coinb(dot)in's bare-minimum implementation of OP_CLTV. (only one pubKey and a locktime)

[Reynaldo]

Consider a multisig setup with an attorney as a required cosigner after your death. The timelocked TX approach works, but you need reliable calendar systems to remind you to refresh it regularly.