pull down to refresh
17 sats \ 7 replies \ @Wizardsardine OP 27 Mar \ parent \ on: How do you tell your heirs about your stack? bitcoin
This is a great critique. Our letter is like a wall of text that smacks you in the face with stuff you've never heard of before. Not very approachable.
The letter is specific to Liana Wallet -- we use miniscript to set up a multisig that locks coins with a primary key but also a recovery key that can't spend the coins until the primary key hasn't been used in 15 months (using a relative timelock). It's more complicated, but it allows a user to store the letter/signing device/seed backup with an executor or family member without having to trust them not to steal.
In this setup, the recovery key would have already been loaded onto the signing device and the heir simply has to pull up a wallet to sign. They need the descriptor to get the wallet to find the keys.
I totally agree with this. It's a great point. I feel like we should remove all links to websites. The letter ought to contain all the information a person needs to get the job done.
The timelocked key is interesting, do you have a letter for the inheritant receiving just that key? I think a good start to a doc package would focus on that, something an inheritant receives while the primary user is still alive: "Hey if I'm dead here's how to use that thing.."
Then maybe there's some coded instructions as a second page that could direct them to the primary key.
Thinking about it that way we're at 3 pages minimum.
Question:
For the primary, can it trivially bump the 15 month timelock at any time? I assume this just means they publish an updated tx... but does it effect the descriptor the inheritant may have stored?
reply
The way we set it up, the user never needs to get the primary key. It's a 1 of 2 where one key is the primary and the second key is the recovery. But the script on the coins doesn't allow the recovery to spend until the primary hasn't been used in 15 months.
The primary can "refresh" the timelocks by sending to self. They have to do this for all their utxos before the relative timelock expires or the recovery key becomes active. It doesn't necessitate a change in the descriptor.
The goal of this whole construction is to avoid "coded instructions" so that inheritants can simply have a key that doesn't work until the primary user is incapacitated or dead--and to do this without needing to trust a third party, using consensus rules instead.
reply
Gotchya, yea I just meant as an option to workaround the 15 months wait or if for example the USB key shits the bed.
I think the important doc to nail then would be to focus specifically on that secondary, then can layer in anything that needs to be coded.
EDIT: Now its coming together, this is focused on that secondary key... something about it initially made me think it was for both keys in the multisig. Guess that circles back to the first impression for someone naive to the setup...
reply
yeah, I'm not even sure the USB is worth it at this point. I guess it's handy for ease of us, but I feel like I've had to chuck so many of them that it may be more trouble than it's worth.
Thanks for your feedback!
reply
I just ninja edited... I see now this is focused on the secondary...
One of the things I've looked into re: USB type data is M-Disc, its not ubiquitous as it once was but still cheap enough for an inheritant to buy a drive if they need to to recover data from a DVD.
reply
the data storage/longevity people love blue rays