Topic: Dead man's switch: better approach proposal - page 2. (Read 995 times)

Hello,

All the ideas of the switch that I came across are generally of three types:

1) Share private keys to heirs before any accident:
Disadvantage: Heirs misbehave risk and additional key compromise risk.

2) Some automatic service, layer or bank deposit box, will send encrypted private keys (predominantly encrypted) to heirs if owner does not demonstrate he's alive every N days.
Disadvantage: There is a third party dependency which may cause keys may be lost forever.

3) An owner should keep funds in time-locked script where heirs can spend in N days. An owner should renew days by transferring to new script.
Disadvantage: Process complexity and transaction fee burden of regular funds re-locking for a new time.

Better approach proposal is the following:

Prerequisites:

Alice posesses some bitcoins which she would like to transfer to Bob in case of some accident. Alice should keep full control of funds so Bob can't get them before the accident. There should be a way to avoid dependency on any intermediaries with minimal overhead. Alice knows Bob's public keys.

Process flow:

• For all Bitcoin inputs which appears under her control, Alice continuously signs but NOT broadcasts Bitcoin transactions with the following properties. The transactions output are to P2SH or P2WSH address where unlock script allows Alice to spend anytime, but Bob to spend in N days after broadcast time. It may look as follows:

• Alice DOES NOT broadcast the transactions but just sends it to Bob (along with unlocking scripts, if needed) and have an agreement with him that he broadcasts ONLY in case of some accident. Bob is motivated now to store the transactions on his side.
• Alice is motivated to check at least in every N days if the transactions were not broadcasted.
• If Bob breaks the agreement and broadcasts or the transactions accidentally hit the chain then Alice will just withdraw bitcoins from their outputs.
• If there is an accident then Bob broadcasts the transactions, waits N days and withdraws the funds.

This way we can avoid disadvantages of the solutions above. However, Bob is responsible to store not only his private keys but transactions set as well. Apart from that, there should be a mechanism to renew transaction set on Bob's side when Alice UTXO's change happens. But this can be achieved without intermediaries.

I've posted this solution proposal as replies in this threads.
https://bitcointalksearch.org/topic/dead-mans-switch-5069728,
https://bitcointalksearch.org/topic/how-would-you-implement-a-dead-mans-switch-5179829
However, I didn't get any feedback so created a separate topic to get more attention.

I'm a developer and thinking if there is a sense for a Proof-of-Concept. Please let me know you thoughts.