[TL;DRWith this approach, any bitcoin holder can safely put crypto assets under inheritance not involving any trusted third party or sharing private keys with heirs in ANY part of a flow. Bitcoin Testnet Proof-of-concept is ready for the first user experience.]

TL;DR
With this approach, any bitcoin holder can safely put crypto assets under inheritance not involving any trusted third party or sharing private keys with heirs in ANY part of a flow. Bitcoin Testnet Proof-of-concept is ready for the first user experience.

I would like to introduce a Broadcast Delay Bitcoin Inheritance Protocol. It already has a proof-of-concept, which is a draft practical implementation, embedded into Testnet Wallet mobile app.

The approach was discussed in this forum a while ago. It improves on existing ways to inherit bitcoins like sharing private keys, dead man’s switch, time-locked escrow P2SH, P2WSH scripts, etc.

It takes an initial setup and some regular status checks from both Bitcoin Owner and Heir.  However, in many cases, that should not be a frequent activity and will not be a high burden for parties if software support is implemented properly.

The implementation covers basic inheritance flows but was not tested intensively and is NOT PRODUCTION READY. It does not cover many edge cases such as more than one heir, UTXO reorganization on the Owner side, backups, etc.

Me and Dmitry Sukhiy were involved in this slow-moving R&D that speeded up a bit recently. The Github fork of the Testnet Wallet is here.

We consider if this protocol is worth being done production-ready as some form of free and open-source implementation. So if you read through it or try the app and share your feedback it will be very appreciated and may help us in the understanding of future development.

[Better approach proposal is the following:]

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:

Code:

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

• 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://bitcointalk.org/index.php?topic=5069728.0,
https://bitcointalk.org/index.php?topic=5179829.0
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.

Hi. It seems that there were no discussions specific to the subject for the last year. So would like to collect a summary regarding the following

• Current status of corresponding BIPs and its development
  
• Any kind of technical or economical obstacles for including into Bitcoin Core release
  
  • New opportunities for business and users if that is released
    
  Thank you.