Topic: Dead man's switch (Read 5366 times)

up

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.


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.

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?

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.

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.

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.

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.

It would be easy to improve the redeem script in the suggested P2SH lock time above-thread to enforce m of n multisig:

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 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.

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.

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?

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.

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.

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?

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.

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.


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.

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.

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.

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.