Dead man's switch

[OmegaStarScream]

A close person to me has asked to create what's called a dead man's switch. When he passes away, his bitcoins will be sent to specific addresses. I know that some people will suggest printing the private keys or giving the seed in his will etc. but that's out of the question in this case.

The funds are under his full control and he has the private keys. How would you suggest me to create this? I'm not really familiar with dealing with commands and bitcoind but I was thinking about getting multiple servers and run bitcoind and then create a program to interact with it?

[HeRetiK]

I'm not sure about the implementation details, but I think the general logic would be as follows:

1) They sign a timelocked transaction using their private key, sending the coins to the target address but not redeemable until date x.
2) The timelocked transaction is stored on your server
3) Before date x arrives, they move their coins to a new address and sign another timelocked transaction using the private key of the new address.
4) Rinse and repeat until date x arrives when your server publishes the timelocked transaction to the network.

This way their private keys never touch the server, they can spent their coins however they like and the owner of the receiving address can't spend the coins until the dead man's switch has triggered.

Alternatively they could also lock a hardware wallet away in a bank tresor and have a dead man's switch email send the passphrase and PIN to unlock said hardware wallet in case of their demise as it's rather unlikely that someone would manage to prematurely get access to both.

[aleksej996]

The best way to do this is by creating a transaction with locked time to send to a specific address.
Then while he is alive, he can move those funds (invalidating the locked time transaction) and create a transaction again.

This is a cost free and simple solution, however if you are doing this on a hot wallet, you will need to keep doing this whenever you move your funds.
I think some wallets (GreenAddress wallet?) already support this.

[Pmalek]

A dead man's switch could be activated in the case that your friend doesn't log in to his computer and enters a password or code every 10 days for example. The moment he stops doing that someone else can receive access to his accounts.

Google has what is called Inactive Account Manager, maybe that could help.
https://myaccount.google.com/inactive?pli=1

Another possibility is that your friend creates emails for the future. The site https://www.futureme.org/ allows you to write an email that will be sent at a specific date in the future. There is a similar service here - http://whensend.com/

Source:
https://www.reddit.com/r/Bitcoin/comments/5s5dzz/dead_mans_switch_for_hodlers/

[aleksej996]

A dead man's switch could be activated in the case that your friend doesn't log in to his computer and enters a password or code every 10 days for example. The moment he stops doing that someone else can receive access to his accounts.

Google has what is called Inactive Account Manager, maybe that could help.
https://myaccount.google.com/inactive?pli=1

Another possibility is that your friend creates emails for the future. The site https://www.futureme.org/ allows you to write an email that will be sent at a specific date in the future. There is a similar service here - http://whensend.com/

Source:
https://www.reddit.com/r/Bitcoin/comments/5s5dzz/dead_mans_switch_for_hodlers/

Using these centralized services would be even worse then putting seed words in your will, as OP mentioned.

[Pmalek]

Using these centralized services would be even worse then putting seed words in your will, as OP mentioned.

The information/seed can be encrypted and the people who will receive the email would already have a way to decrypt the message but they would need the email to do so. 

[mixoftix]

use Multisignature Application in 1-of-2 method..

more info: https://en.bitcoin.it/wiki/Multisignature

[aleksej996]

Using these centralized services would be even worse then putting seed words in your will, as OP mentioned.

The information/seed can be encrypted and the people who will receive the email would already have a way to decrypt the message but they would need the email to do so. 

Still it is safer and more reliable to encrypt the seed words in your will then to use some website that will likely not exist in 10, let along 30-50 years.

use Multisignature Application in 1-of-2 method..

This is just as good as giving the other person your private key right now.

[mixoftix]

use Multisignature Application in 1-of-2 method..

This is just as good as giving the other person your private key right now.

Well, look at the responsibility of involved people in both solutions. in multisignature you could engage your attorney in the process and he/she never could spend your money with his/her secondary account without your permission on contract. if you give the other person your only private key, you will lose the advantages of non-repudiation that comes with asymmetric encryption.

[cellard]

A dead man's switch could be activated in the case that your friend doesn't log in to his computer and enters a password or code every 10 days for example. The moment he stops doing that someone else can receive access to his accounts.

Google has what is called Inactive Account Manager, maybe that could help.
https://myaccount.google.com/inactive?pli=1

Another possibility is that your friend creates emails for the future. The site https://www.futureme.org/ allows you to write an email that will be sent at a specific date in the future. There is a similar service here - http://whensend.com/

Source:
https://www.reddit.com/r/Bitcoin/comments/5s5dzz/dead_mans_switch_for_hodlers/

Im not convinced on that method. The computer that you are using to log in could break, either due a software or hardware error, due being stolen, due a fire happening or other accidents... then what, it takes more than 10 days to recover and the coins are moved and you are still alive.

The only way to guarantee coins move when you are dead is implanting yourself some sort of heart rate monitoring chip which sends the coins when it goes to 0... of course this is absolutely insane.

So far I would focus on not dying, if I had bitcoins, I wouldn't trust what happened to them if I died, so don't die is the best solution right now.

[ABCbits]

There are many ways if he rely on trusted people or 3rd party which already mentioned by others.

Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :

Code:

OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV <Bob's Public Key> OP_CHECKSIG
OP_ENDIF

[KingZee]

I can think of a few ways to do this with a smart contract, but in bitcoin it's a bit harder.

I'm not sure about the implementation details, but I think the general logic would be as follows:

1) They sign a timelocked transaction using their private key, sending the coins to the target address but not redeemable until date x.
2) The timelocked transaction is stored on your server
3) Before date x arrives, they move their coins to a new address and sign another timelocked transaction using the private key of the new address.
4) Rinse and repeat until date x arrives when your server publishes the timelocked transaction to the network.

This way their private keys never touch the server, they can spent their coins however they like and the owner of the receiving address can't spend the coins until the dead man's switch has triggered.

This is basically the solution but it's kind of redundant.
A simpler one would be to just sign the tx that would spend all his coins right now. And store that transaction on a server. Write code in your favourite language that broadcasts the tx after Y amount of time just for an added layer of security. And open up a port on your server where the application can listen to.

If the application doesn't get pinged once every X months, weeks, whatever, then it calls the function, and after Y amount of time, the tx will be broadcasted.

So he has to ping the server every X interval, and if he somehow fucks up and forgets, he has Y more time to stop the application from broadcasting his coins.

Hell if you want I can probably set this up for you in node.js right now.

[bob123]

~snip~

This is basically the solution but it's kind of redundant.
A simpler one would be to just sign the tx that would spend all his coins right now. And store that transaction on a server. Write code in your favourite language that broadcasts the tx after Y amount of time just for an added layer of security. And open up a port on your server where the application can listen to.

If the application doesn't get pinged once every X months, weeks, whatever, then it calls the function, and after Y amount of time, the tx will be broadcasted.

So he has to ping the server every X interval, and if he somehow fucks up and forgets, he has Y more time to stop the application from broadcasting his coins.

Hell if you want I can probably set this up for you in node.js right now.

That's not really redundant.

Your solution involves trust. OP could theoretically broadcast the transaction earlier (e.g. working together with the recipient).
This should definitely be considered.

Heretik's solution on the other hand doesn't involve any trust.
The owner of the coins is the only one who can initiate that transaction (by not creating a new one).

IMO that's the best solution for a dead mans switch (at least the best i can think of).

[KingZee]

That's not really redundant.

Your solution involves trust. OP could theoretically broadcast the transaction earlier (e.g. working together with the recipient).
This should definitely be considered.

Heretik's solution on the other hand doesn't involve any trust.
The owner of the coins is the only one who can initiate that transaction (by not creating a new one).

IMO that's the best solution for a dead mans switch (at least the best i can think of).

Yes I've been thinking about it for a while, you could do this with only one timelocked tx.

You craft the transaction that will spend the coins from his existing addresses, to address A.

You craft a timelocked transaction from the output that still doesn't exist inside address A, that spends these same coins to the addresses of his buddy. This timelocked tx can be for example when OP is a 100 years old.

Broadcast the second tx. And don't spend the original coins.

That's it. Now he only needs to create a "switch" to spend his coins to the address A whenever he dies. A button on his phone when he's on his deathbed, or something.

In case he's still alive, he also owns the private key to address A, so he can invalidate the timelocked tx by sending the coins back to himself it if fuck-ups happen.

[bob123]

Broadcast the second tx. And don't spend the original coins.

Broadcasting the second transaction won't work, since it is invalid.

It will be rejected by the network. So it would have to be stored on a server or something like that.

That's it. Now he only needs to create a "switch" to spend his coins to the address A whenever he dies.

The whole thread is about creating such a 'switch'. Your 'solution' unfortunately isn't a solution. It is just a different approach which still needs the key element, the 'switch'.

A button on his phone when he's on his deathbed, or something.

And what if the phone gets stolen ?
Of what if it breaks ?

Or what if he gets ran over by a bus ?

This definitely has to be done automatically. Therefore the timelocked transaction. If the owner isn't intervening, the transaction will be valid (the 'switch').

[aleksej996]

use Multisignature Application in 1-of-2 method..

This is just as good as giving the other person your private key right now.

Well, look at the responsibility of involved people in both solutions. in multisignature you could engage your attorney in the process and he/she never could spend your money with his/her secondary account without your permission on contract. if you give the other person your only private key, you will lose the advantages of non-repudiation that comes with asymmetric encryption.

I think you are thinking of 2-of-2 multisig, not 1-of-2.
1-of-2 means that either of the keys can unlock the funds.

1-of-n multisig transactions are equivalent to sharing your private key with n people, as anyone can spend it.

2-of-2 multisig wouldn't work here though, unless you want to not be able to spend your coins without your attorney's permission.

There are many ways if he rely on trusted people or 3rd party which already mentioned by others.

Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :

Code:

OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV <Bob's Public Key> OP_CHECKSIG
OP_ENDIF

Or you could just create the transaction with timelock as said above and it won't be included in the block until that time is up.
Creating non-standard transactions is risky, as they are not always accepted by miners.
If you have a standard solution and timelock is as simple as it gets, since every transaction already contains this value, then it is probably better to use it that way.

That's it. Now he only needs to create a "switch" to spend his coins to the address A whenever he dies. A button on his phone when he's on his deathbed, or something.

I don't know why you are insisting for there to be some live program running when there is such a simple solution already stated with timelocks. There is absolutely no need to create any new programs or servers for this.
Bitcoin was already designed from the beginning supporting these things.

Timelock value exist in every transaction, they are just set to 0 by default in most wallets.

[KingZee]

I don't know why you are insisting for there to be some live program running when there is such a simple solution already stated with timelocks. There is absolutely no need to create any new programs or servers for this.
Bitcoin was already designed from the beginning supporting these things.

Timelock value exist in every transaction, they are just set to 0 by default in most wallets.

To be honest you're right. I was writing a response to bob123 but after you wrote your post I abandonned because regardless if we can make it work, why not just broadcast one tx?

Make a timelocked transaction that spends his coins when he's a 100 years old, or a 120, some time that he obviously won't reach.

Broadcast it and that's it.. If he decides to spend his coins before that, then do it, otherwise, they'll be transferred to his friend.

But as a quick answer to you bob123 :

1. HeRetiK's solution also stores the timelocked transaction on a server.
2. You can easily change my solution from "press a button to send the tx", to "press a button occasionally before to prevent the tx from being sent from the server."

My solution also doesn't expose his private keys, or endanger his money, all of those are only known to him. The server holds 2 transactions to addresses he already owns.

[HeRetiK]

That's it. Now he only needs to create a "switch" to spend his coins to the address A whenever he dies. A button on his phone when he's on his deathbed, or something.

That's not a dead man's switch though, that's just a... switch

The whole idea behind a dead man's switch is that it's triggered by the inactivity of the dead-man-to-be rather than by a last second attempt to send off a signal (the latter which could faile due to the dead-man-to-be's untimely demise).

Make a timelocked transaction that spends his coins when he's a 100 years old, or a 120, some time that he obviously won't reach.

Broadcast it and that's it.. If he decides to spend his coins before that, then do it, otherwise, they'll be transferred to his friend.

Prematurely broadcasted timelocked transactions are invalid and ignored by the network. That's why additional application logic is needed to broadcast the timelocked transaction after the timelock has passed.

But as a quick answer to you bob123 :

1. HeRetiK's solution also stores the timelocked transaction on a server.
2. You can easily change my solution from "press a button to send the tx", to "press a button occasionally before to prevent the tx from being sent from the server."

My solution also doesn't expose his private keys, or endanger his money, all of those are only known to him. The server holds 2 transactions to addresses he already owns.

The timelocked transaction does absolutely nothing until after the timelock has passed however, that's the beauty of it If the server gets compromised or the software fails for some other reason, a regular transaction would cause the coins to move prematurely. With a timelocked transaction you have the added security of the Bitcoin blockchain.

[aleksej996]

Make a timelocked transaction that spends his coins when he's a 100 years old, or a 120, some time that he obviously won't reach.

For practical reasons it is even better to create timelocked transaction with something he could live to, like 1 year and then just spend those outputs at least once a year to a new address from which he can create a timelocked transaction again.

As I said, I think GreenAddress wallet already does this automatically for you.
I am not sure if they are open source, they have a lot of repos on their Github page https://github.com/greenaddress

Prematurely broadcasted timelocked transactions are invalid and ignored by the network. That's why additional application logic is needed to broadcast the timelocked transaction after the timelock has passed.

They can't be included in a block until the timelock is reached, but I do assume that they stay in the mempool for a while.
Still, it makes since that you should keep your wallet running at least until few days before you die, so it doesn't disappear from the mempool. Most wallets, including Bitcoin Core, will keep broadcasting your transaction until it is included in a block.

[HeRetiK]

Prematurely broadcasted timelocked transactions are invalid and ignored by the network. That's why additional application logic is needed to broadcast the timelocked transaction after the timelock has passed.

They can't be included in a block until the timelock is reached, but I do assume that they stay in the mempool for a while.
Still, it makes since that you should keep your wallet running at least until few days before you die, so it doesn't disappear from the mempool. Most wallets, including Bitcoin Core, will keep broadcasting your transaction until it is included in a block.

If I recall correctly nodes usually drop transactions off their mempool within 3-4 days or so. Maybe after a bit longer, but definitely a timeframe that's too short to be practical for a dead man's switch. That is assuming a not-yet-spendable transaction is kept around in the first place.

Good point about wallets keeping rebroadcasting transactions. In the case of a dead man's switch I personally would probably double and triple check that the wallet does indeed keep rebroadcasting the transaction but if it does you could keep the surrounding application logic at a minimum (if additional logic is even necessary at all).