Topic: Dead man's switch: better approach proposal (Read 1117 times)

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://bitcointalksearch.org/topic/m.58735037

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.

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

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.

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.

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

∙After the address was funded, the timer will start [1].
∙Alice can spend the fund anytime.
∙After , 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, 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.

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.

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

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.

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.

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.

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.


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.


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


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

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

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

Yeah I got this part.

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?

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

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.

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

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

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