pull down to refresh
0 sats \ 2 replies \ @Zk2u 28 Jun 2022 \ on: How to prepare for your death so your family has access to your wallets? bitcoin
Our approach at Valera is likely going to be a 2 of 4 multisig system (once we get schnorr on LN so we can use FROST for threshold schnorr magic).
2 keys on users phone, one synced e2ee with their cloud provider and one in the mobile’s local storage (preferably HSM?) (or not, maybe both are e2ee synced)
Another held by Valera
Another held by user by not hot, only in their will, presumably in a safe manner like tamperproof bag, metal engraved plate etc.
If not the death certificate, maybe a signature from the key that was stored safely.
Then we’ll notify the owner’s device saying that the key has been accessed and that a wealth transfer is imminent (we will cooperate with the paper key unless we hear from the owner)
If we get a signed response from one of the other keys that only the original owner had (idk) before a timelock we won’t sign the wealth transfer, or something. Not 100% yet ofc. This requires trusting us to be available there.
There are a few mods to this strategy that could be used to achieve different goals too.
Evolving this IRT
Instead of trusting us not to sign even if we get a signature to not cooperate, we keep a live set of death close txs on the user’s device that update when channel updates happen.
These deathclose txs would be fully signed and valid, and close channels directly into a timelocked contract. From this contract, one of the two keys on the user’s device could spend immediately, or the safety key kept away for death can spend after a certain (configurable?) time period.
These txs are then encrypted to the safety key’s public key, and published publicly. They are perfectly valid but can’t disrupt anything unless the safety key is activated, decrypts the tx and broadcasts it.
Now the original user’s device is completely aware of these transactions’ existence (it created them after all) so every time it periodically syncs transactions relevant to its UTXOs via Neutrino, which would pick up these deathcloses if ever broadcast. The device can then send a local emergency notification that the key has been activated and to open the app. Upon opening, user gets details of what’s happening and provides authorisation for the wallet to broadcast cancellations and reopens the channels.
Of course, it all gets a little more complicated when you introduce multi-device FROST signatures for the onchain savings account but that’s for another day lol
reply
Worth noting in this second one, the “multisig” layout works out as a normal 1-of-1 but with valid channel closures (deathcloses?) signed by that singular hot key to a recovery key that can redeem those funds as long as the initial key is not “alive”.
We don’t need schnorr for this method; this is doable now.
reply