pull down to refresh
10 sats \ 0 replies \ @Wizardsardine OP 15h \ parent \ on: LIana Wallet v10 is out! bitcoin
Liana uses miniscript, and at the moment seed signer doesn't have support for miniscript. Seems like more and more projects are implementing miniscript every day, so let them know it's an important feature for you and we'll do our best to help out.
Liana v10 released! New easy wallet backups (even your last used derivation index so you don't accidentally reuse an address when you restore/migrate your wallet).
Check it out: https://wizardsardine.com/blog/liana-10.0-release/
@BTCsessions did a pretty great tutorial last month.
You can find most of the video tutorials we've made on our support page.
if it contains the seed, all of this is just extra layers
Not in this case. The seed given to the heir is actually one seed in a 1-of-2 multisig (this is why they need the descriptor--whatever wallet software they use to recover needs to be able to know how to find the coins), but it's a 1-of-2 where the primary key (held by you) can always spend and the heir's key (stored with this letter) can only spend coins if the primary key isn't used for a prespecified length of time. This is enforced by Bitcoin script at the consensus level, so not trusting a third party.
The advantage to this is exactly what you are getting at: an executor or your heir won't be able to spend your funds until you want them to (or stop using your key) even if have access to the seed/hardware signer/letter.
they should at least understand what it is
You are spot on. This is a really important point. At least with current pop understanding of Bitcoin, an heir who has no real idea about it may be very casual in their approach to recover (or just ignore it).
Thanks for the feedback!
it reaches the recipient with detailed instructions and almost all the Bitcoin available inside the hardware wallet
This is the big question. We use a relative timelock to lock the coins so that this recovery key cannot spend them until a pre-specified length of time after the primary key has been used (as much as 15 months).
If a person becomes dies, it may indeed take some time for people to sort through belongings and wills. If it takes more than 15 months, the hardware device will definitely have an active key that can spend all the funds.
Also, if the person hasn't used their primary key recently (say in the last year), then it is also pretty likely that the key on the hardware wallet will have the ability to spend the funds.
You're point is definitely worth thinking about.
Perhaps a safer method—and one that could also reduce the size of the letter
Also great point. Keeping the descriptor separate from the seed is safer, but it also adds complexity. Additionally, email addresses change or stop being checked. You could see a world where a user sets this up and then 10 years go by and the beneficiary email they designated is no longer in use. I think we've opted for a situation where everything needed to recover the funds is needed.
As for the Cryptosteel, does it contain everything necessary to recover the wallet?
The cryptosteel only has the seed. You still need the descriptor to recover the wallet. Currently this is stored on the USB drive or as an opt-in alternative on a Wizardsardine server.
Still trusting Bitkey to make the hand off so the beneficiary can access the funds.
What if Bitkey decides the beneficiary shouldn't get access to the funds?
Relative timelocks fix this.
This is cool. I went through it a couple times with different personas in mind and it gave me the suggestions I would have suggested myself. Well done!
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!
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.
The language in the letter isn't for someone naive to this whole concept, both in terms of vernacular and proper nouns. A successful cookbook will be have to be iterated to use non-Bitcoiner language and concepts.
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.
I'm also not clear on what value multi-sig is adding here, the added descriptor just makes the process more failure prone.
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.
Standardiztion is another goal, at some point your website/product becomes another SPOF
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.
it's not ideal. But unless you plan on a treasure hunt, you should think about how you're going to tell them about it. Any tips?