Topic: Bitcoin Inheritance Protocol with delayed broadcast (improved Dead Man's Switch) (Read 345 times)

Exactly, there is no need for any third party. Alice implements the spending rules and then shares 2 params and 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.

As I got it the spending rules of  E address should be implemented by Alice herself which means the omission of any third party involved into  Inheritance Protocol you have proposed.    Is this correct?

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.

I think it really depends on the specifics of the person's situation. It is probably best for someone with any meaningful amount of assets to employ an estate lawyer to draft a plan to have assets moved upon your death. An estate lawyer can advise you based on your specific circumstances how quickly and how much of your assets can be transferred. This is probably one reason why the OP's proposal would not work well, as what may work in some jurisdictions may not work in all.

In general, the location the person died determines the jurisdiction of any probate court, or any rules regarding limitations on the transfer of assets.

Which brings up some other points which is in a lot of places your debts die with you. Except for debt that is covered by real property. i.e. the $5000 someone owes Chase MasterCard will die with them. The $50000 they owe on the mortgage will stay attached to the property. Taxes will vary. But, in some places you can't transfer the property till the debt is paid so the property stays in the estate till the mortgage is paid off. [Side note of real life I had to deal with this along with a friend for a place in Arizona. What a pain.] In other parts of the world other debt might follow the estate. In others it all goes away as you are required more or less to have insurance to cover property debt.

I think that is always going to be part of the problem too. BTC is world wide, how do you create a setup that will work in all the jurisdictions around the world and keep up with them as they change. And so on. Along with contested wills, and other potential things.

Just because it can be done, does not mean it should be done. And then where do you draw the line?

But, this is drifting a bit OT, it's not about the ramifications of the BTC transfer, but about the transfer itself.



Taxes usually have very little to do with it. It's is the person getting the money really entitled to it? We can disagree with the law(s) all we want. But for now in many parts of the world there are very strict rules covering how an estate is distributed. Going around them although doable and common even without BTC can cause and have caused years of legal issues for people if others choose to fight it. And I am going to say this and leave it alone, until you have had dealings with a contested will over an amount of money that is worth less then a cheap used car you have no idea of the shit storm that can happen over a bit of money.
As for the executor not giving the person entitled to it the information needed. They could just as easily not had over cash accounts, or titles to property or a dozen other things.


-Dave

And I'm asking why should there be an executor? We've designed a system in which we transact without having an intermediary, just like cash, but we need an executor to inherit? We don't. The system allows trustless inheritance.

Your solution:

Alice wants from Charlie to receive 1 BTC from her when she passes away. Thus, she creates a 2-of-2 multi-sig wallet, deposits the bitcoin and gives one key to Bob, the executor, and the other key to Charlie. When she dies, Bob gives his key to Charlie. Now, Charlie has access to the money.

Flaw: Bob may not give the key for a million reasons. It's down to him if Charlie gets the money or not.

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

My solution:

Alice wants from Charlie to receive 1 BTC from her when she passes away. Thus, Charlie creates a wallet, gives her an invoice, she signs a transaction where she gives the bitcoin, but adds a condition that the transaction is valid after a specific time period. If she's alive after this period, they redo the process. If she's gone, Charlie can broadcast the transaction and get the money.

You may need to state it officially that you're inheriting Alice's assets and therefore get taxed, but I find no reason to use an intermediary for that purpose. In most countries bitcoin is considered an unrealized gain, so you may not even need to state you're even inheriting it.

The problem with the OP's solution, and with a multisig setup, is that you (effectively) must tell your (future) heirs that they are receiving an inheritance ahead of time, and that you cannot revoke the inheritance or change the amount without it being obvious to your heirs.

In some cases, a person may tell their heirs about their inheritance, but I think most of the time, the specifics are kept private.

This really depends on state law, and the specifics of the person's estate. For example, you may be able to designate an account as payable on death that will allow the bank to automatically transfer ownership of the account to your designated beneficiary upon your death, without the beneficiary having to wait for probate.

You will want to be sure that your assets outside of your POD accounts are sufficient to cover your debts and any tax liability, otherwise your creditors (or the tax collector) may come after those who received the POD accounts, which can be unpleasant.

The person who is supposed to get the BTC has 1 of the keys.
The executor of the estate has another.

The problem is it will always be a static address so you are probably better off with wallet seed words that are split between 2 people.
You can then use you wallet normally and when you die the executor hands over their words to the person getting the wallet who then would have complete access to it.

The other option is using a hardware wallet that you just imported seed words into with a pin. The recipient of the funds would have had the wallet file and the hardware wallet.
The executor just hands over the pin. You don't even need an executor for this as there are many deadman send email services out there.

It's important to note here, in a situation like this in many many many parts of the world you NEED to have human involvement. There has to be someone handling the estate you cannot (legally) just hand over money. That is the crux of it. I can leave Julie just about everything I want. BUT, I just can't have it automatically happen. There needs to be a will and an accounting of what is what. I had a friend who had to fly to a foreign country in the middle of the pandemic for a reading & acceptance of a will. Just handing over funds although doable will probably cause more grief then it's worth.

-Dave

He may not want to, but accidentally lose them. He may get stolen. There are lots that can happen until you pass away if another person holds your private key. It's much better to just give them a signed transaction that is not yet valid instead.

How does multi-sig helps the situation? I don't understand.

I think part of the problem here is that the way I see it, it's an answer in search of a question.

And here is where I am going to get a ton of people yelling at me about about not your keys not your coins, but as of now I think that a lot of people who are concerned about leaving an inheritance in BTC are the same ones using custodial services like Coinbase. And for the ones that are not, they are more then likely enough to be leaving their BTC to people who understand it enough to be able to use an X of Y multisig wallet with one of the keys not being released until after death.

-Dave

If it's someone I don't completely trust, I'd be even more worried knowing they get my money in case I die! That's an "accident" waiting to happen.

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.

To me this sounds a bit like Lightning Network, where you send back and forth transactions representing the current channel state that can be published at any time and include a lock time so cheating attempts can be detected and mitigated if checking in often enough.

If it's implemented the same way as in LN commitments, it should work fine. By resending a new transaction from time to time, it can also account for mining fee fluctuations and with long enough lock time it won't require a watchtower or checking in manually way too often.

I don't think the 'escrow address' is really needed; the commitments can send money directly to the kid's address (with lock time on the utxo though), just as in LN.

What I think would make more sense implementation-wise (as also suggested in the other thread); would be simplifying to e.g. a shellscript that creates those transactions which can then be submitted with any client you want. The commitments can be transferred however secure way one prefers, which can be PGP encrypted e-mails, encrypted messengers or whatever. If this is really for the sake of inheritance, it can't be based on a phone app that itself (and / or its servers) might not be around by the time someone using it actually dies and wants to inherit their coins.

---

Off-topic, but not sure if you need to cryptographically secure your BTC from someone you want to inherit it to. Like, this whole mechanism (over e.g. leaving behind an instruction on how to just get access to your wallet(s)) is to make sure they don't try to steal your coins before you die. Not sure I'd want to inherit my holdings to a person that I feel could try stealing my possessions.

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.

---

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.

[moderator's note: consecutive posts merged]

If I understand correctly, address A belongs to Alice. Address A can send to any address upon the signature of address A.

Address B, belonging to Bob, Alice’s son, (the associated private key) can also cause unspent outputs from address A to be sent from address A to address B. The private key associated with address B can spend any output from address A, but only after x blocks since a transaction was sent to address A from address B. Address A can spend any output from address A to address B at any time.

The above means that the benefactor can spend some of his coin without having to provide an updated transaction or key to the heir.   

Excuse me from asking, but how does that differ from the current locktime feature? Currently, you can sign a transaction and state that it will be valid after a certain block or datetime. Thus, you can sign your inheritance and if it's going to be valid without you being dead, you can spend the funds, making it invalid.

The people who will inherit your property will only have given you their master public key.

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.