in case of death; mandatory bitcoin deathswitch Dead man's switch

[Kakmakr]

Even though we do not know when we are going to die, it may happen in 40 or 50 years from now, when the technology might be obsolete. Now, I know people will adapt to the chances whilst they are alive, but what happens if the "death switch" fails and it takes a couple of years to access those coins.

In that time, a lot could change.... we might have a hard fork to counter quantum computing attacks or we might need some major changes to the protocol that negate a new attack vector that might be found.

You do not want the coins/tokens locked up due to a faulty "death switch" or if your relatives has no idea how to access the coins. (The death switch might transfer the coins to their addresses ...but they might not know how to access it safely.)  

[1714031483]

1714031483

[1714031483]

1714031483

[1714031483]

1714031483

[PrimeNumber7]

I believe that 40 years or so a call to free lost coins will begin.

Any address that has not had a withdrawal in 40 years will be listed as an abandoned account and have 1 year or 2 years to do a withdrawal. It will will then forfeit and go back to the fund of coins left to mine.

LN (and other layer 2 protocols) will make it less necessary, and less common for particular outputs to be spent.

If you have a sufficient number of channels, and if your counterparties are cooperating, you may never need to close your channels because you can just rebalance your various channels.

Further, there are always security risks associated with accessing your private keys and spending your coin, so individuals should generally not spend their coin unless they need to.

Sure, Bitcoin is code, but how would Bitcoin know that you're dead?

It can't. Period.

If someone wants to, they could create a nLockTime transaction that is valid a very long time in the future, that is intended to be sent to an address created for their next-of-kin. This is ultimately something that the owner of any coin should decide.

I would point out that some wealthy people choose to not give any money to their heirs.

[Pmalek]

My favourite solution is the timelock dead man switch with nLocktime, which is described in this thread. The problem is that the popular wallets don't make it too easy to create this kind of transactions.

Another problem is that you don't know when you are going to die. Let's assume you want to leave your coins to your children. You set up a timelock with nLocktime at a future block around the time you will turn 70. But if you suffer a heart attack and die at 60, your children will have to wait 10 years to get access to the coins. It would be great if timelocked transactions could be edited to broadcast earlier upon showing the needed cryptographic proof. I don't have much knowledge of the subject, maybe they already can. 

I don't know if you ever wondered what would happen to all your email addresses and online accounts if you die without leaving your backup passwords to your family members or lawyer.

I have heard of examples where Facebook has given the parents of a missing child access to their Facebook account in order to see if they can retrace their last steps or find some clues from the messages with their friends. In a way, social media accounts are inheritable. I don't see why that couldn't work for email accounts as well.

[o_e_l_e_o]

You set up a timelock with nLocktime at a future block around the time you will turn 70. But if you suffer a heart attack and die at 60, your children will have to wait 10 years to get access to the coins.

There are easy ways around this, as I briefly explained here: https://bitcointalk.org/index.php?topic=5394317.msg59853530#msg59853530. To elaborate:

The first scenario would involve me keeping the timelocked transactions secret, such as locked in a safe in my house or a safe deposit box at a bank. My family know about where they are stored, but would only be able to access them after I die. For added security they could be encrypted with a key only my family know. I create and sign a timelocked transaction, locked 1 year (for example) in the future, and hide it in my safe. If I am still alive in 11 months, then I create and sign a new timelocked transaction a year in the future from now, destroy the old one, and and replace it with the new one. Repeat every year and your family will never have to wait more than a year to claim your coins (or whatever time frame you choose). If you wanted you could even make up decades worth of timelocked transactions in advance, with a new one unlocking every month (for example), and just destroy them one by one as time goes on.

The second scenario would involve me sharing the timelocked transactions with my family as soon as I sign them. Again, 11 months in the future, I move a single input from the timelocked transaction, thereby invalidating the entire transaction (I could even keep a single input of a few thousand sats which I repeatedly use only for this purpose), and then create and sign a new one and hand it over to my family.

[n0nce]

Sure, Bitcoin is code, but how would Bitcoin know that you're dead?

It can't. Period.

I know, it was a rhetorical question.

You set up a timelock with nLocktime at a future block around the time you will turn 70. But if you suffer a heart attack and die at 60, your children will have to wait 10 years to get access to the coins.

There are easy ways around this, as I briefly explained here: https://bitcointalk.org/index.php?topic=5394317.msg59853530#msg59853530. To elaborate:

The first scenario would involve me keeping the timelocked transactions secret, such as locked in a safe in my house or a safe deposit box at a bank. My family know about where they are stored, but would only be able to access them after I die. For added security they could be encrypted with a key only my family know. I create and sign a timelocked transaction, locked 1 year (for example) in the future, and hide it in my safe. If I am still alive in 11 months, then I create and sign a new timelocked transaction a year in the future from now, destroy the old one, and and replace it with the new one. Repeat every year and your family will never have to wait more than a year to claim your coins (or whatever time frame you choose). If you wanted you could even make up decades worth of timelocked transactions in advance, with a new one unlocking every month (for example), and just destroy them one by one as time goes on.

The second scenario would involve me sharing the timelocked transactions with my family as soon as I sign them. Again, 11 months in the future, I move a single input from the timelocked transaction, thereby invalidating the entire transaction (I could even keep a single input of a few thousand sats which I repeatedly use only for this purpose), and then create and sign a new one and hand it over to my family.

I thought about these 2 proposals of yours and I can't come up with anything better; they hit a nice balance of usability, security and low risk of the heirs not being able to access the coins. I also don't find them very impractical or too inconvenient to implement in real life, so for now this would be my preferred solution for a 'dead man's switch'. Compared to other ideas it also doesn't involve any custom crypto, which is great.

[o_e_l_e_o]

and low risk of the heirs not being able to access the coins.

The biggest risks for the heirs not being able to access the coins (as I see it) is either them not being able to access the timelocked transactions, or losing access to the address which the timelocked transactions send all your coins to. Probably the most simple way to mitigate these risks would be to combine the methods above, and store a copy of your timelocked transaction in your safe as well as handing them a copy to store, so there is not a single point of failure for the timelocked transaction. This would obviously necessitate the "spend an input to invalidate the transaction" method for replacing the timelocked transactions. And while you are at it, they could hand you a copy of the seed phrase or private key for the target address to back up for them (assuming they don't use that wallet for anything else) in a location they know about, although you shouldn't keep this in the same place as the timelocked transactions for obvious reasons.

You could also circumvent this by using SIGHASH_NONE and SIGHASH_ANYONECANPAY, which would allow your heir to specify the output of the timelocked transaction to any address they like. This however introduces an additional risk in that anyone with access to the timelocked transaction could steal the funds after the timelock expires.

Other risks would be you forgetting to invalidate and replace the timelocked transactions, or messing up and creating an incorrect timelock without realizing it.

[d5000]

Another problem is that you don't know when you are going to die.

o_e_l_e_o already answered for me - the point is that you can replace the nLocktime transactions regularly.

Just wanted to add that there is another variant I linked in my earlier post in this thread, invented by forum user Andriian and implemented in an experimental version of a mobile wallet, which in some situations can be even better:

You give your heirs an already signed transaction with two IF_ELSE options: a CSV timelock (after the expiration they can access the coins freely) and a condition that you can move the coins with your own key when you want. They can broadcast it at any time, but when they broadcast it, they need to wait for the timelock to expire to move the coins, for example for a year.

So they can broadcast it as soon you've died and will have access after the timelock expires. If they maliciously broadcast the transaction while you're still alive, you can move the coins yourself (and speak some serious word with your heir, which may not be a heir anymore in this case ).

This variant has a little bit more trust involved, because in theory you could imagine rare situations where you won't be able to move your coins in time (while still alive, e.g. on a long extreme tourism trip) and your heir could abuse that, but is easier to implement because you don't need to replace transactions as long as you don't move your coins - so it's excellent for a longterm HODL wallet. Even if someone steals the transaction (which could be a paper with a QR code) from your heir and broadcasts it, you will have enough time to react.

[DannyHamilton]

It should be mandatory to give (at least) three addresses upon wallet creation.

Mandatory how?  Who will enforce this rule? This is a decentralized, global technology. Anybody anywhere, with some software engineering knowledge, can create their own wallet software and make it available for others to use. How are you going to force every programmer in the world that creates any type of wallet software to require all of their users to provide 3 addresses? Are you going to employ a police force that will hunt them down and arrest them? Will you also arrest the people that choose to USE a wallet software that doesn't require 3 addresses? What if someone doesn't have any friends or family that they trust? Do they get to use bitcoin?

Bah. You want to use a wallet with a multi-sig system? Go ahead, nobody is stopping you. But you aren't going to force your personal preference on the entire world.

[Pmalek]

<Snip>

I like this proposal even more than the nLocktime feature. With Andriian's solution, there is no need to re-create the timelocked transaction after a certain period has passed. To invalidate the old one, you would have to spend one of the inputs thereby creating additional transaction costs. Not that big of a deal, but still. Or if you don't want to do that, you can create a timelocked transaction for a decade in advance, but you would be leaving your heirs waiting for a long time to get to the coins.   

But with Andriian's method, the sender would only need to create a new timelocked transaction if the receiver tried to broadcast it while the sender is still alive. In other cases, the sender only checks the status. That's good and it doesn't even have to be done that often. If the transaction timelock expires in one year, the sender would only have to check the status one time during that period.

But there are some negatives as well. No wallet uses Andriian's proposal. It only works in a testing environment and on a mobile wallet. If you wanted to use it, both parties would be required to use that one and only wallet. There is no desktop solution yet. Even if it was live on mainnet, it would have to be thoroughly checked and tested for bugs and vulnerabilities before being recommended.

But I hope he succeeds in creating this. It looks really interesting.     

[thepriceinsats]

thoughts/cons?

My wife shares the knowledge of where things are stored and the backup plates are stored separately in the event of my demise, that's prudent planning. But I am not trusting a third-party app with my keys.


The comment about abandoned accounts of over 40 years was interesting, that's something that should be discussed.