Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: OmegaStarScream on November 15, 2018, 12:26:47 PM



Title: Dead man's switch
Post by: OmegaStarScream on November 15, 2018, 12:26:47 PM
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?


Title: Re: Dead man's switch
Post by: HeRetiK on November 15, 2018, 03:01:51 PM
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.


Title: Re: Dead man's switch
Post by: aleksej996 on November 15, 2018, 03:04:11 PM
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.


Title: Re: Dead man's switch
Post by: Pmalek on November 15, 2018, 03:11:22 PM
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/


Title: Re: Dead man's switch
Post by: aleksej996 on November 15, 2018, 03:17:18 PM
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.


Title: Re: Dead man's switch
Post by: Pmalek on November 15, 2018, 03:48:00 PM
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. 


Title: Re: Dead man's switch
Post by: mixoftix on November 15, 2018, 03:49:59 PM
use Multisignature Application in 1-of-2 method..

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


Title: Re: Dead man's switch
Post by: aleksej996 on November 15, 2018, 03:51:06 PM
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.


Title: Re: Dead man's switch
Post by: mixoftix on November 15, 2018, 04:02:55 PM

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.


Title: Re: Dead man's switch
Post by: cellard on November 15, 2018, 04:23:03 PM
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.


Title: Re: Dead man's switch
Post by: ABCbits on November 15, 2018, 05:36:54 PM
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


Title: Re: Dead man's switch
Post by: KingZee on November 15, 2018, 06:37:57 PM
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.


Title: Re: Dead man's switch
Post by: bob123 on November 15, 2018, 07:04:18 PM
~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).


Title: Re: Dead man's switch
Post by: KingZee on November 15, 2018, 07:12:57 PM

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.


Title: Re: Dead man's switch
Post by: bob123 on November 15, 2018, 07:20:06 PM
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').


Title: Re: Dead man's switch
Post by: aleksej996 on November 15, 2018, 07:28:35 PM

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.


Title: Re: Dead man's switch
Post by: KingZee on November 15, 2018, 07:37:35 PM

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.


Title: Re: Dead man's switch
Post by: HeRetiK on November 15, 2018, 07:46:24 PM
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.


Title: Re: Dead man's switch
Post by: aleksej996 on November 15, 2018, 07:53:38 PM
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.


Title: Re: Dead man's switch
Post by: HeRetiK on November 15, 2018, 08:19:29 PM
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).


Title: Re: Dead man's switch
Post by: mixoftix on November 15, 2018, 11:01:44 PM

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.

No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.






Title: Re: Dead man's switch
Post by: bob123 on November 16, 2018, 07:01:02 AM
No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.

But again.. this approach requires trust.

Yes, you could track the 'abuse' in terms of you'd know who spend these coins.
But you wouldn't be able to 'revert' it or anything else.

The coins would be gone in this scenario. The best approach is a trustless approach. And this does exclude the option of a 1of2 multisig with giving 1 key away.


Title: Re: Dead man's switch
Post by: mixoftix on November 16, 2018, 08:31:41 AM
No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.

But again.. this approach requires trust.

Yes, you could track the 'abuse' in terms of you'd know who spend these coins.
But you wouldn't be able to 'revert' it or anything else.

The coins would be gone in this scenario. The best approach is a trustless approach. And this does exclude the option of a 1of2 multisig with giving 1 key away.

so, we have HASHED TIME LOCKED CONTRACTS (HTLC) in bitcoin that works with the concept of PROOF-of-Payment and even could provide *reversible* transactions to the payer or re-route it to 3rd address. this only needs to open payment channels.

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

** if there are no other technical considerations, now we have an ALICE1-ALICE2-CHARLIE relationship in a dead scenario. Alice owns two accounts, Alice1 and Alice 2. Alice will have her bitcoins accessible by submitting a random digital content with Alice1 which triggers a transaction to Alice2. if this digital content does not submit before a specified future time, then could automatically re-route to CHARLIE.


Title: Re: Dead man's switch
Post by: apexcrypto on November 17, 2018, 04:33:29 PM
Why not just encrypt your seed with PGP, put the encrypted text in your will, and store the
password in your bank safe deposit box. You could even give the recipient a BIP39 password now, without the seed
so that only they can access the btc if/when the seed is decoded, presumably after you are dead and
your safe deposit box has been opened.


Title: Re: Dead man's switch
Post by: aleksej996 on November 17, 2018, 08:32:33 PM
so, we have HASHED TIME LOCKED CONTRACTS (HTLC) in bitcoin that works with the concept of PROOF-of-Payment and even could provide *reversible* transactions to the payer or re-route it to 3rd address. this only needs to open payment channels.

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

** if there are no other technical considerations, now we have an ALICE1-ALICE2-CHARLIE relationship in a dead scenario. Alice owns two accounts, Alice1 and Alice 2. Alice will have her bitcoins accessible by submitting a random digital content with Alice1 which triggers a transaction to Alice2. if this digital content does not submit before a specified future time, then could automatically re-route to CHARLIE.

It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

Using timelock you will be able to use any kind of transaction (segwit, legacy,multisig) it doesn't need no special conditions.
Also you will have better support with more wallets and miners supporting it.

There really shouldn't be any need to complicate things like this. This is a very simple and old problem.

Why not just encrypt your seed with PGP, put the encrypted text in your will, and store the
password in your bank safe deposit box. You could even give the recipient a BIP39 password now, without the seed
so that only they can access the btc if/when the seed is decoded, presumably after you are dead and
your safe deposit box has been opened.

This should also work in it's own way. It is simpler to setup then using timelocks, although it moves a bit of complexity to the party that receives the inheritance.

It is also slightly less secure since it depends on trust of seed words not being obtained prior to the persons death.
So it's not as insecure as putting a private key in a will, since anyone would be able to steal it.
However from the perspective of a user that holds the password, the security is the same as if that was the private key.

So in conclusion, not as elegant, but perhaps easier to setup for the person that is writing a will.


Title: Re: Dead man's switch
Post by: aliashraf on November 17, 2018, 08:52:59 PM
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 DROP <Bob's Public Key> OP_CHECKSIG
OP_ENDIF
With above modification (DROP opcode is mandatory here and added by me), this is the ultimate solution.

That said, besides including its hash in the output script of her P2SH transaction, Alice has to give above redeem script to Bob somehow and she should keep updating Bob regularly about the latest redeem script version. One solution may be to treat the whole process like part a formal will. In 90 days after Alice has passed, Bob would be able to claim the balance using the latest redeem script he has received.

The code shows the beauty of CHECKSEQUENCEVERIFY opcode and its wide range of applications. unlike legacy nLockTime alternative which is transaction level and prevents the whole transaction from getting into blockchain and being effective, OP_CSV provides locking mechanism for tx outputs which makes such applications possible.

P.S.
I just don't get it by the way, why should we continue arguing once the solution has been presented?. The post I quoted from @ETFbitcoin was submitted few hours after op, I suppose.


Title: Re: Dead man's switch
Post by: mixoftix on November 18, 2018, 08:26:32 AM
It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

simply, just in the case Alice has complicated scenarios for her will.

--------------------

but there is one serious question here about "Transaction malleability":
https://en.bitcoin.it/wiki/Transaction_malleability

which of solutions above are not vulnerable to malleability?


Title: Re: Dead man's switch
Post by: bob123 on November 18, 2018, 03:28:14 PM
It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

simply, just in the case Alice has complicated scenarios for her will.

--------------------

but there is one serious question here about "Transaction malleability":
https://en.bitcoin.it/wiki/Transaction_malleability

which of solutions above are not vulnerable to malleability?


Transaction malleability doesn't influence the scenario and the outcome of the transaction.

What transaction malleability basically is, is that you can take a broadcasted transaction and change a 'value' (not possible to change receipent/amount/fee) to generate a new hash ('basically same' transaction, just a different hash).

This is a problem for not-that-good coded exchanges which rely on the transaction hashes when withdrawing funds.


But this doesn't have any influence in this scenario since it doesn't change anything important.


Title: Re: Dead man's switch
Post by: aliashraf on November 18, 2018, 09:24:27 PM

Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.
I afraid there are some flaws in this paragraph:

One should note that CHECKSEQUENCEVERIFY is a relative lock time operator. For Alice to "refresh" his script there may exist two different reasons:
1)She needs to spend part of her balance and leave the remaining for Bob to inherit just in case.
2) she just wants to make it possible for another period.

In either case the "90d" parameter doesn't need to be changed (unless Alice might want to reconsider her policy), timer is reset and starts ticking from the moment the new script is confirmed. Bob should supply this constant number, 90d, in his redeem transaction in nsequence field (in spite of the fact that he needs to supply the raw script which again carries this parameter) as a result, bitcoin doesn't let Bob transaction in the blockchain, unless its input (hopefully Alice latest tx output) is aged at least 90 days (no script processing involved yet). When the time comes and Bob transaction is basically ready to be confirmed, bitcoin runs the script he has provided (as its hash is used in Alice P2SH transaction) and the script checks the nsequence field (second access into this field) for being matched with "90d" parameter of op_CSV, ... it is how it works.

Still Alice needs to refresh Bob in both cases!  

It is because Alice has to expose her public address every time she spends her latest tx and as a best practice she needs to avoid reusing it in the new transaction. It implies new script pattern and new hash hence Bob should be informed about this new hash (remember? Alice is using P2SH address in her transaction) and its raw script.


Title: Re: Dead man's switch
Post by: OmegaStarScream on November 22, 2018, 09:20:23 AM
I appreciate everyone suggestions and apparently, the way to go would be using time-locked transactions.

I'm afraid I haven't given all the details so would it change anything If for example, he wants to send a certain amount on a weekly basis until all funds left his wallet? or the same logic should apply?


Title: Re: Dead man's switch
Post by: aliashraf on November 22, 2018, 09:54:58 AM
I appreciate everyone suggestions and apparently, the way to go would be using time-locked transactions.

I'm afraid I haven't given all the details so would it change anything If for example, he wants to send a certain amount on a weekly basis until all funds left his wallet? or the same logic should apply?
Not a big deal. Though my question would be whether "he" wants to pertain access to his funds to be able to stop the weekly payment process (like when the heir behaves improperly or passes away because of an accident or somethin)? If positive (more likely) he could just make a transaction with multiple outputs with the same script as what @etfbitcoin has proposed with OP_CSV parameter adjusted to <7 days>, <14 days>, ... for each P2SH output and they follow the same relative lock time logic discussed above thread.

Note that there would be multiple redeem scripts that should be handed to heir and should be kept uptodate if the owner decides to interrupt or revise his policy.


Warning:
Avoid any solution that somehow requires a third party service, a trustee, anything other than your legacy wallet api, otherwise you are ignoring the whole purpose of what you have paid for: bitcoin.




Title: Re: Dead man's switch
Post by: Ucy on November 22, 2018, 05:20:03 PM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.


Title: Re: Dead man's switch
Post by: Pmalek on November 22, 2018, 07:29:22 PM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
But then there is another problem. That solution could result in the coins not getting released to the next of kin in time or ever if the majority of the family want that for any reason.


Title: Re: Dead man's switch
Post by: aliashraf on November 22, 2018, 08:24:49 PM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
It would be easy to improve the redeem script in the suggested P2SH lock time above-thread to enforce m of n multisig:
Code:
OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV DROP 2 <Bob's Public Key> <Carol's public key> <Daniel's public key> 3 OP_CHECKMULTISIG
OP_ENDIF


Title: Re: Dead man's switch
Post by: Ucy on November 23, 2018, 10:31:38 AM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
But then there is another problem. That solution could result in the coins not getting released to the next of kin in time or ever if the majority of the family want that for any reason.

The family members don't need to know the purpose of the question. All they need to know is that the program was created by the owner to be sent out in the future in the time of his death or disappearance. There should be some kind of proofs that confirm it is coming from the real owner.


The owner could even program it to do a lot of things like to release the coins if he becomes absent for too long.


Title: Re: Dead man's switch
Post by: OmegaStarScream on December 03, 2018, 09:26:30 AM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.

Having funds released in these cases is fine. It doesn't necessarily have to be death, being away for long time as a trigger could work as well. The less people or services used in the process, the better.


Title: Re: Dead man's switch
Post by: DaCryptoRaccoon on December 05, 2018, 06:25:47 AM
The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.

Having funds released in these cases is fine. It doesn't necessarily have to be death, being away for long time as a trigger could work as well. The less people or services used in the process, the better.

If you were planning on creating something for this purpose you could craft some kind of software that the user must interact with in a specific time frame say 30-60 days using some form of keys.
This way would allow use of encryption to "authenticate" the user and to execute the payments or release info if the user failed to submit a key in a set time frame the software could either broadcast a transaction that could be stored encrypted and becomes decrypted and broadcast if the user fails to interact or submit a key or token to the software in a set period.

Or the keys could be held in encrypted container format and the decryption key is released if there is no interaction with the software in the specific time frame.




Title: Re: Dead man's switch
Post by: DaCryptoRaccoon on December 16, 2018, 12:05:14 AM
I had a quick search about for similar things that might be good reference points to create a system for this purpose.

I found this email that has something interesting in it.

https://mailing-list-archive.cryptoanarchy.wiki/archive/1995/09/b15b1c8ebf07eff21cc1f67e7002a4a47c90d635e234bd863352ab37b36cbbe5/

7. National Semiconductor's "Commercial Cryptography Ideas
      for Success" (9 pp. of large type) This contains
      graphics of the CAKE program and a "Proposed NIST Escrow
      Certificate Heirarchy" which cannot be easily
      distributed by us, so we offer this by fax.

There was also some relation to the idea of.

You could use a trusted parties. p  then incorporate a threshold scheme or signature structure in order to hide the key (k) to your encrypted message enck(M).
Whenever you don't update those trusted parties, after (t) time, they can connect to each other and if they reach the threshold or can sign with the correct signatures it then releases the key k

p(k)~enck(M)~(t)

https://faculty.nps.edu/dedennin/publications/Descriptions%20of%20Key%20Escrow%20Systems.htm

another good reference for descriptions of Key Escrow systems.




Title: Re: Dead man's switch
Post by: almightyruler on September 01, 2019, 09:40:13 AM
Have just come across this interesting thread.

An idea: the timelocked transaction could send a small portion of the funds as fees, to a key which is known publicly, in order to encourage people to broadcast it to the network at the appropriate time.

It would be a free-for-all once the transaction is accepted by the network, since technically anyone can sweep the "broadcast fee" sent to a publicly known key, but it would ensure there's a good chance the transaction is broadcast in the first place.

To further increase adoption, the fee address could be standardized, so that anyone could run a daemon which watches the mempool for timelocked transactions that reference the address. They then save that transaction, and queue it to be re-broadcasted (along with the transaction to grab the fee) once the lock expires.

Thoughts?


Title: Re: Dead man's switch
Post by: Andriian on September 16, 2019, 09:30:49 AM
I was trying to think of solution for the same problem and came across this old thread during my research. So would like to share the following ideas, which can be seen as improvements to this process.

Aside from process where Bob give his public key to Alice for first time, Alice could write a script which :
1. Make exactly same script, expect timestamp/block height modified for next 90 days
2. Spend Bitcoin from older P2SH transaction and send it to same address with new script
3. Send newer script to Bob (through email perhaps)

Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.

The steps are as follows:
Similarly, Bob gives his public key to Alice.
1. Alice creates special spend bitcoin transaction(s) from all Bitcoin UTXOs under his control to P2SH address. The unlock script of the address allows Alice to spend anytime, but Bob to spend in N days (with OP_CSV).
2. Alice DOES NOT broadcast the transaction but just sends it to Bob and have an agreement with Bob that he broadcasts ONLY in case of some accident. Bob is motivated now to store the transaction(s) on his side.
3. Alice is motivated to check if transaction was NOT broadcasted (which results in decrease of his walled amount) at least every N days.
4. If Bob breaks the agreement and broadcasts or the transaction(s) accidentally hits the chain then Alice will just withdraw bitcoins from the P2SH locked output of the transaction(s).
5. If there is an accident with Alice then Bob broadcasts the transaction(s), waits N days and withdraws bitcoins.

The advantages comparing to the previous methods are:
1. Alice can use any type of addresses to store her bitcoins but not just specific P2SH scripts so complexity reduce and network fee reduce when spending coins.
2. Alice should not move her bitcoins from one P2SH locking script to other every N months. Complexity and network fee reduce again.

The disadvantages which are still there:
1. Alice still needs to create transaction(s) to cover new UTXO set which appears under her control and communicate it to Bob. This might happen every time when she receives BTC or spends and gets a change.

Please, let me know if this approach makes sense, has any mistakes or it was already discussed somewhere.