Dead man's switch: better approach proposal

[Andriian]

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.

[1714918537]

1714918537

[1714918537]

1714918537

[AB de Royse777]

Please let me know you thoughts.

To me it's a better approach than any of the idea I had in my mind. Good one.

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.

I am not much into coding or technical things, how a regular user can perform this task?

I didn't get any feedback so created a separate topic to get more attention.

Sorry about this, in this forum there are a lot of gem like this in undiscovered. A kind of collateral damage :-P

[Andriian]

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.

I am not much into coding or technical things, how a regular user can perform this task?

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.

[DaCryptoRaccoon]

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.

I am not much into coding or technical things, how a regular user can perform this task?

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.

Cicada were working on a Key Escrow System.
Not sure if it was ever released as such.

[AB de Royse777]

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

Yeah I got this part.

It can be new wallet software with this functionality or an add-on to existing one.

As far as I know there are no existing wallet that supports to set an option of N days so, I am asking do you have a script or are you working in it to make it easier for the regular user?

[Andriian]

It can be new wallet software with this functionality or an add-on to existing one.

As far as I know there are no existing wallet that supports to set an option of N days so, I am asking do you have a script or are you working in it to make it easier for the regular user?

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

[lightningmelo]

It can be new wallet software with this functionality or an add-on to existing one.

As far as I know there are no existing wallet that supports to set an option of N days so, I am asking do you have a script or are you working in it to make it easier for the regular user?

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

I don't know of anything that exists with bitcoin script, but there's FinalMessage.io which is a custodial dead man switch, might want to check that one out

[ABCbits]

I was confused when read your reply, but now i think i understand what you're talking about.

Your solution still falls on type 3 if you didn't mention wallet which automate the process. Even so, it requires both Alice and Bob use same wallet, unless there's standard (such as BIP) where other wallet might adopt the standard.

• If Bob breaks the agreement and broadcasts or the transactions accidentally hit the chain then Alice will just withdraw bitcoins from their outputs.

This parts is similar with LN network where dishonest user attempt to broadcast earlier state of channel, which require honest user online 24/7 or use watchtower.
And AFAIK your idea suffer same problem.

It can be new wallet software with this functionality or an add-on to existing one.

As far as I know there are no existing wallet that supports to set an option of N days so, I am asking do you have a script or are you working in it to make it easier for the regular user?

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

AFAIK there aren't any wallet which allow you make P2SH/P2WSH transaction.

I don't know of anything that exists with bitcoin script, but there's FinalMessage.io which is a custodial dead man switch, might want to check that one out

But then we're back to the older problem where higher degree of trust is required.

[Welsh]

I was confused when read your reply, but now i think i understand what you're talking about.

Your solution still falls on type 3 if you didn't mention wallet which automate the process. Even so, it requires both Alice and Bob use same wallet, unless there's standard (such as BIP) where other wallet might adopt the standard.

If you were setting up a dead mans switch for your family member then this could likely be agreed, and would only be a small compromise. Just like people setup wills, and trust other people to handle it after their death which is a massive compromise considering the trust factor within that. Switching to the same wallet is a rather minor compromise in my opinion for what seems to be a better solution to most other proposals.

[pooya87]

Switching to the same wallet is a rather minor compromise in my opinion for what seems to be a better solution to most other proposals.

I'd agree since it's compared with method where 3rd party is required. But it could be major compromise if the wallet isn't actively developed where the security is questionable and it could be discontinued anytime.

things like this proposal don't have to be a full wallet since all they do is creating a scriptPub that is not common. so they can simply be another feature in the already existing wallets. if the wallets didn't add the feature it still can be built on top of them. for example with a very small amount of code it could be built on top of Electrum. that way it doesn't really have to change/maintained over time and it still relies on a wallet that you may trust.

[Andriian]

Your solution still falls on type 3 if you didn't mention wallet which automate the process. Even so, it requires both Alice and Bob use same wallet, unless there's standard (such as BIP) where other wallet might adopt the standard.

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.

This parts is similar with LN network where dishonest user attempt to broadcast earlier state of channel, which require honest user online 24/7 or use watchtower.
And AFAIK your idea suffer same problem.

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.

AFAIK there aren't any wallet which allow you make P2SH/P2WSH transaction.

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

I don't know of anything that exists with bitcoin script, but there's FinalMessage.io which is a custodial dead man switch, might want to check that one out

But then we're back to the older problem where higher degree of trust is required.

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.

[nc50lc]

-snip-

• If Bob breaks the agreement and broadcasts or the transactions accidentally hit the chain then Alice will just withdraw bitcoins from their outputs.
  

Isn't this the same as number 3's input(s) re-spending to make another TX to extend the n_locktime target?
If Alice needs to withdraw from the accidentally broadcasted tx, then there's an on-chain transaction and fees involved
thus, basically the same as #3.

I found 3 the most convenient option, but it's possible to create a client that utilizes the concept for ease of use.

3 Disadvantage: Process complexity and transaction fee burden of regular funds re-locking for a new time.

For the fee, a one-input one output transaction isn't that expensive even with an overpay 50+ sat/B fee, average of 200B, that's 0.0001 per update.
Trice a year or Quarterly, it won't be too expensive (plus the fee rate could be lower than 50).

For the complexity, it will only became complex if Alice accidentally broadcasted the transaction prematurely,
that would require her to clear her node's mempool or wait for it to expire (and -zapwallettxes) to re-spend the input(s) involved.
Otherwise, She can just create another tx to "extend" the lock-time since Bob's or others' node won't accept/relay that particular TX.

[Andriian]

Isn't this the same as number 3's input(s) re-spending to make another TX to extend the n_locktime target?
If Alice needs to withdraw from the accidentally broadcasted tx, then there's an on-chain transaction and fees involved
thus, basically the same as #3.

I found 3 the most convenient option, but it's possible to create a client that utilizes the concept for ease of use.

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.

I know LN time lock generally far shorter. But what if Alice forget to re-new the transaction and Bob spend the coin as soon as time lock duration expired? With high transaction fees, Alice only have about 10 minutes attempting to cancel / double-spend Bob's transaction.

The same answer is here.

[Andriian]

For the fee, a one-input one output transaction isn't that expensive even with an overpay 50+ sat/B fee, average of 200B, that's 0.0001 per update.
Trice a year or Quarterly, it won't be too expensive (plus the fee rate could be lower than 50).

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.

For the complexity, it will only became complex if Alice accidentally broadcasted the transaction prematurely,
that would require her to clear her node's mempool or wait for it to expire (and -zapwallettxes) to re-spend the input(s) involved.
Otherwise, She can just create another tx to "extend" the lock-time since Bob's or others' node won't accept/relay that particular TX.

Sorry, I didn't get the point here. type 3 is about this kind of locking script where Alice can spend anytime:

Code:

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

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.

[nc50lc]

Sorry, I didn't get the point here. type 3 is about this kind of locking script where Alice can spend anytime

Sry, I got CSV and nLocktime mixed up since Type3 can be achieved either way and the disadvantages are identical.

So it goes like this:

Code:

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

∙After the address was funded, the timer will start [1].
∙Alice can spend the fund anytime.
∙After <N days>, Bob can spend the fund in case something happens Alice.

[1] Alice will create a transaction that will send her bitcoins to that address but wont broadcast it, RAW tx will be sent to BOB.
This way, <N days> wont be active.
If Bob decided to broadcast the tx and it got included to a block, the address will be funded, thus will start the timer.

That will work even without automation.
A notification system should work to minimize the work for Alice to check every week/day if the address was funded.
But still doesn't totally solve the "fee" and "complexity" problem since Bob can broadcast the tx anytime
that will require Alice to make another Time Lock script (another transaction to transfer the funds) in order not to expose the redeem script and public keys for privacy (or future security) reasons.

This partially breaks the "trustless" system.

[Andriian]

A notification system should work to minimize the work for Alice to check every week/day if the address was funded.
But still doesn't totally solve the "fee" and "complexity" problem since Bob can broadcast the tx anytime
that will require Alice to make another Time Lock script (another transaction to transfer the funds) in order not to expose the redeem script and public keys for privacy (or future security) reasons.
This partially breaks the "trustless" system.

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

[Dabs]

This is interesting. I'm currently using multiples of the second option right now, so I am dependent on third parties, but many of them. Hopefully not all of them go down. I find it unlikely Google will go down any time soon, and there might be ample time to see the signs if they do.

The alternative is to create your own system, but that relies on running your own software or hardware, or even paying for an online service (VPS, hosting, etc) to run your software.

For long term hodling and coins not being actively used for anything (like trading or staking or mining), cold storage or paper wallets work. Or even hardware wallets or open dimes.

In my case, I don't have too many coins so I just simply got life insurance. Which I recommend everyone gets. It's a contract and works within the legal system. You die, she gets paid. All you gotta do is make sure you can cover the premium.

DIY or tech system would be considered the "premium" if your proposal ever gets an implementation, I think.

[aliashraf]

Congrats OP, you helped the community with a crucial issue by your solid proposal. It was really smart  

I have been discussing this problem a while ago and nobody proposed keeping the original transaction unpublished while Alice is alive and using its timelock for her to prevent greedy heirs from exposing the transaction, brilliant!  

It is why we do always need to think and re-think every problem instead of sticking with what has been temporarily agreed upon, no matter how obvious it would look like.

BTW, the exposure of Alice's pubkey to Bob is not a big deal as long as we have not commercial QCs around, like for decades, imo and when it is time to resist QC, Alice can use new tech for her postponed private transaction.

[PrimeNumber7]

• If Bob breaks the agreement and broadcasts or the transactions accidentally hit the chain then Alice will just withdraw bitcoins from their outputs.

This parts is similar with LN network where dishonest user attempt to broadcast earlier state of channel, which require honest user online 24/7 or use watchtower.
And AFAIK your idea suffer same problem.

The LN user actually only needs to be online once every (time_to_claim_malicious_tx - reaction_time - time_to_reasonably_get_tx_confirmed). If a LN channel is opened such that a person can claim the entire balance of the channel within 36 hours of an old channel state being broadcast, if it takes 1 hour to react, and 5 hours to be certain their tx will be confirmed, the person will need to be online once every 30 hours to protect their funds.

If bob (the owner of the coin) can claim the entire balance from an intermediary tx within 31 days of the tx being confirmed, he will only need to check the blockchain once every 31 days minus 6 hours. He should not use a watchtower the same way LN channels use watchtowers because there are some cases in which he wants the person broadcasting the tx the ability to move the coin to their own address (when the original owner of the coin dies).

[Andriian]

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.