Exactly, there is no need for any third party. Alice implements the spending rules and then shares 2 params <Alice Public Key> and <N days> with Bob along with the signed (but not broadcasted yet) tx from A to E.
So when the tx is broadcasted to E each of the parties can spend from E by reconstructing spending script from the params.

Normally this is Bob (a heir) who will broadcast the tx and spend from E when inheritance time comes.

P.S. As I figured it out recently answering posts in this topic, the process can be even more simplified with elimination for the escrow (E) address  And some parts of this approach still can be used. I'll share more details later as I need to put some effort for simple explanation.

After reading all the above replies I realised that may be the inheritance problem can be split in two aspects: heir's legal right for bitcoins and physical ability to get it.

The legal part depends on jurisdiction and is hard to predict, implement for all possible cases and keep up to date. The physical part is purely on protocol layer and universal around the globe.

The system can be modular and consist of two layers accordingly. The physical layer should be implemented as a set of applications or services.
The legal part support can be in a form of some kind of plugin or may be not present. So many jurisdictions can be covered gradually step-by-step or implemented by third-party as if plugins in modern browsers.

It is up to heir if to take funds before legal approval and have troubles with the consequences or wait for permission. Still physically trustless but legally optionaly dependent and location specific.

It looks like in that way many of the questions above can be solved.

Yes it works the same way as Lightning Network in terms of cheating attempts detection. And that is true that mining fee is something that should be taken care of. However, not necessarily you need to monitor fee fluctuations and resend new transaction to Heir from time to time. It should be possible to construct such a transaction that you solve it once and forever. The ways to do it I can think off:

• You can construct not one transaction but many of them with different fees so Heir is to choose which one is the best when it is time to broadcast
• You can sign the transaction by not covering all inputs and outputs. e.g. SIGHASH_SINGLE|SIGHASH_ANYONECANPAY signing rules can help you with that. So Heir is able to add some inputs and outputs to increase fee.
• Child Pays For Parent technique

But if you send money directly to the kid's address with lock time on the utxo then you need to "move" bitcoins to new locked utxo each time when the time is close enough. In the approach proposed you don't need to move anything but just monitor from time to time. The latter is 1) more convenient: faster than signing and broadcasting, can be automated via watchtower services 2) more secure: you don't need to deal with you private keys.
Note that there is no "lock time" (nLockTime + CheckLockTimeVerify) in this protocol. What is used is "relative locktime" (nSequence + CheckSequenceVerify) according to the Bitcoin spec https://en.bitcoin.it/wiki/Timelock


Not sure I understand about the shellscript and in which cases it may be more convenient (for non-technical user) than UI app. Can you please share me the thread by the way.
That is true that you can't rely on your phone as a Heir. Mobile app customisation is just the best way we found to implement the concept and let everyone try and feel how it works. For real production ready implementation there should be some software support to backup not only Heir's private keys but the transactions as well, hardware wallet support for better security, dealing with changing UTXO set on Owner's side, etc. All that we can figure out looks implementation-feasible unless someone can point if we missed something here.


Fair enough. However, even if someone fully trusts heirs, there is still a risk of compromise Heir's private key and inheritance info so an attacker can steal money. Yes, this approach still does not guarantee that 100% but at least makes it much harder for the attacker IMHO.
As other argument, I think there should be some subset of Owners that can't fully trust Heirs. For example, people sometimes change in worse way some day or just hide their nature. Don't believe this happen too often but, still, this may be a subject to market research to have more precise data about customer needs.
And finally, a Heir is not obligatory a physical person. It can be a some company or charity fund. I such a case, I think, there are even less guarantees that the Heir entity behaves honestly all the time in the future because you may deal with more than one specific person belonging to the organisation. An Owner may not be sure about all of them but it is still better for him to allow the company inherit when the time comes than BTC to be lost forever for everyone.

Добрый день

На тот случай если кто-либо еще отслеживает и интересуется этой темой, можете заглянуть в эту ветку https://bitcointalk.org/index.php?topic=5377228.msg58735037#msg58735037
Там есть информация уже о практической реализации моего протокола о котором говорил zasad@ в самом начале этой ветки форума.
Реализация встроена в форк известного Bitcoin Wallet. Можно выкачать APK по ссылкам в посте, установить на Андроид проиграть сценарии наследования на Bitcoin Testnet. Там же есть детальное описание протокола и скриншоты простого пользовательского сценария.

P.S. Tак уж совпало что я тоже говорю на русском и с удовольствием обнаружил эту дискуссию в прошлом году.

Hi

I case if anyone still follows this topic, there is a continuation of it in this one where you can try the first Proof-of-concept embedded in to the Bitcoin Wallet https://bitcointalk.org/index.php?topic=5377228.msg58735037#msg58735037

That's correct

That is not quite true. There are not 2 but 3 addresses in the schema: A (Alice), B(Bob), E(Escrow). A and B are just some regular addresses (like P2PKH) where only one private key can spend. No person can spend from other person addresses.
And then we have address E which has spending rules like this:

I can quote this paragraph to help understanding the role of the E address. It is from this site

Alternatively you can skim through the app screenshots to understand the flow.

From user experience it is easier for Owner to go this way than with locktime feature.

Let's suppose an Owner (Alice) have signed some locktime transaction, which spends some of her UTXO's to some address under Heir's (Bob's) control. Alice shares transaction to Bob. The transaction becomes valid at some time X, so only after that time it can be broadcasted by Bob.

From this point each time when the time X is soon enough but Alice is still alive she needs to: 1) spend the funds to invalidate the old locktime tx 2) create new locktime tx 3) share it with Bob.

On the contrary, with broadcast delay of CSV-based transaction Alice needs to do nothing except checking if her bitcoins haven't beed moved to the escrow address. The check should be more simple, and sometimes even more safe than doing the 3 steps above.
For example the check in the proof-of-concept app UI looks like this:
https://static.wixstatic.com/media/0b2b15_c4c18c1f3a404700aa233bfebf0c1345~mv2.png/v1/crop/x_0,y_0,w_1080,h_726/fill/w_305,h_205,al_c,q_85,usm_0.66_1.00_0.01/0b2b15_c4c18c1f3a404700aa233bfebf0c1345~mv2.webp
You just need to open the wallet and it will show you the status once synchronised with network.

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.

Hi Everyone,

There is a simple proof-of-concept implemented and hosted here https://andriianchestnykh.github.io/btc-safe-inherinance/. (I don't have good skills in Frontend development so far)
It works on Bitcoin testnet3. Even though mnemonics should not be exposed outside of a browser and will not operate with mainnet, still DON'T use mnemonics from real Bitcoin funds.

You can have some hands on experience with the inheritance schema discussed above by the following steps:

1) Generate two mnemonics somewhere (will probably add generation functionality here as well) and put into owner and heir mnemonic fields.
2) Get testnet bitcoins from some faucet into owner's address, which will appear once you input valid mnemonic.
3) Wait for the first faucet tx confirmation and click Refresh blockchain data button.
4) Now you can create signed transaction by clicking on Sign intermediate tx under every owner's utxo.
5) Transaction will not be broadcasted but just appear under Transactions column.
6) Now you can broadcast you transaction with Broadcast button. It will be broadcasted and new utxo appear under Intermediate addresses column.
7) Now you can either wait for 6 confirmations for the utxo in the intermediate address and withraw to heir or wait only one confirmation and withdraw to owner.

The PoC repo is here https://github.com/AndriianChestnykh/btc-safe-inherinance. Feel free to fork, change and test it locally. PR's with improvements and Github issues are welcome as well.

We are trying to figure out what can be done to increase chances for the industry adoption: BIP proposal, support libraries or services, etc. so please let me know if any ideas here.

As far as I know, Satoshi created software first to check if everything works as expected. Bitcoin whitepater was written by him/her only after the implementation and just before approaching community.

By the way, that process is vise versa to what most of other crypto projects are doing. That may be even a single case. At least, I don't know other examples in crypto when a whitepaper was created only after a software is ready for production.

Redeem script and public keys of Alice are exposed to Bob once the transaction is transferred to him. Privacy broken here for all Alice addresses involved in the transaction (at least Bob knows them now)
Yes if Bob broadcasts before accident, Alice will withdraw from the lock script to ANY output under her control. Even if Alice only suspects that Bob is going to play dishonest game she will move funds to other outputs.
At this point Alice funds are absolutely safe from Bob (tx can't spend outputs twice) although are not partially private. It is now up to Alice to decide what to do next: create another inheritance transaction to Bob, break the relationships with Bob, involve another heir, etc.

Notification system is something that can work on Alice mobile or even can be checked by Alice manually in some simple cases. Say, if lock period is 3 months, check once a months is enough. Either way checks can do not discover Alice addresses to the world.

I don't know what you mean by "trustless" system exactly, however, I see that:  privacy is partially broken - YES, any kind of intermediary in the process - NO

Good point. It may be not that expensive when there is re-sending of only one or a few outputs. But it can be more expensive if Alice needs keep her funds split to many outputs for privacy purpose. However, some additional analysis is needed here.

Sorry, I didn't get the point here. type 3 is about this kind of locking script where Alice can spend anytime:
I guess, this statement should partially make sense for Bob but not Alice.

Basically, in terms of complexity I mean that:
1) Leave bitcoins where they are. Alice does not even need to move funds to new locking script when she enables this kind of recovery. Just leave bitcoins in the same outputs where they are. That may be important for business needs with technical dependencies on existing set of addresses / UTXOs.
2) May reduce error prone / inconvenient operations: Sign and transfer to Bob new incoming payments (not urgent) but no regular re-spends of each output (urgent before deadline). Especially if Alice herself represents multisig schema of M-of-N partners.
3) Reverse watching. In type 3 Bob may watch Alice via chain if she forgets to re-spend. Alice has no idea if he's watching. In new proposal that is vice versa. Alice is watching if Bob abuses her trust.

That is different, although I'm not sure if I explained it clear enough.
The point here is that Alice does not need to re-spend transaction to extend to new CSV target. She creates transaction where inputs are any UTXOs belonging to Alice but outputs have CSV target for Bob's public key (in ELSE clause). Bob gets this transaction from Alice directly and keeps it on his side (inside wallet storage, e.g). No broadcasting, no keeping in peer mempool, etc.
That's it until accident, assuming Alice does not spend inputs that transaction targets. No more actions like re-spending are needed from Alice unlike in type 3 option. The relative lock clock will start ticking only when there is an accident and Bob broadcasts.


The same answer is here.

It still shouldn't fall on type 3 as there is no need to move bitcoins onchain to new CSV locked output when current one expires for heir. Owner watches if transaction was not broadcasted and organizes transaction and scripts delivery to heir, but never puts it onchain and pays fees. However, I agree that there is still a need to create this wallet functionality or the BIP, which may be even better.


Lightning network lock period is much smaller (no more that a few days, if I'm not mistaken) than that of which can be used in the schema. For example, 3 months locking on the output of broadcasted transaction should not bee too big period for heir to wait before getting full control over the bitcoins and, in the same time, this will not make owner to be online 24/7 or use watchtower. A manual check one time in a month should be enough in this case.


Neither do I, if not take into account simple M-of-N multisigs which are technically P2SH/P2WSH.


Yes a service type like FinalMessage.io has disadvantages as higher degree of trust. However it doesn't look to be custodial which can have full control of owner's funds. It keeps only 1 key in 2-of-3 multisig schema. So it may cause funds to be forever lost but not stolen.
Apart from that, such kind of service has other advantages comparing to the proposed schema:

• Better privacy: A service will never know which are actual owner addresses and balances. This will not happen even in the case when one of three private keys is decrypted somehow by service. It will never know all three public keys to construct 2-of-3 multisig hash which is an owner address.
• Better privacy again: A heir will not know which is actual owner address and balances up until receiving the private key from the service. Here we assume that heir already has 1 private and public key and other owner's public key, so missing only one public key (to be derived from service private key)

So that may be personal owner preferences what is more essential for her: privacy or no third-party dependency.

P.S. This brings up an interesting task of third-party decentralization with minimal overhead, to take the best of both approaches.

I don't have anything implemented yet. One of the topic goals is to find out if that already exists somewhere. Don't want to reinvent the wheel ))

Alice (owner) will just set an option of N days in a wallet. Then the wallet creates transactions automatically when sees new UTXO under control. Then it will send it to heir via some standard peer to peer channel (email, messenger, etc.) From Bob's (heir) side a wallet will get and store the tx.
It can be new wallet software with this functionality or an add-on to existing one.

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

A good suggestion was proposed in this specific message in the thread https://bitcointalk.org/index.php?topic=5069728.msg48001975#msg48001975

Recently, I posted an improvement for the suggestion https://bitcointalk.org/index.php?topic=5069728.msg52468729#msg52468729

I didn't get any feedback for now. Hopefully, will get it in one of the threads.

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.

That was my misspelling. Graftroot is correct one. Here is Gregory Maxwell's proposal for it https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html

P.S. Have fixed subject in the initial message as well