pull down to refresh

0 sats \ 0 replies \ @Wizardsardine OP 2 May \ parent \ on: Have you ever used a timelock to lock bitcoin? bitcoin
exactly! just curious about general level familiarity with timelocks and what they can be used for.
> put in the work and stack sats
> make intricate treasure map puzzle to find keys
> wife and family struggle for years but finally solve
> still can't spend because sats are timelocked
> darth chuckle
It's hard to tell whether people put arbitrary data in the witness because of the op_return limit or because of economics:
Using an op_return to put data in a transaction is cheaper for payloads smaller than 143 bytes (ignoring the current 83-byte limit), while over 143 bytes the witness is cheaper.1
The op_return limit certainly seems to be effective, but it is also true that for larger amounts of data (anything over 143 bytes) it's probably going to go into the witness anyway.
Either way, it does feel like a contradiction: if filters don't work then why do you need to get rid of them? However, it may be more nuanced: filter isn't stopping the behavior, it's just moving it.
Footnotes
Thanks for joining!
- There are a lot of ways you can do it. Most basic is this: you do the set up entirely on your own.
You set up a wallet with 1 primary key (this is your key which you use to spend from the wallet) and 1 inheritance/recovery key. For this key, coins are timelocked for some a customizeable length of time (up to ~15 months). As long as you use your primary key to spend the coins (even just as a self-send to refresh the timelock) before the timelock expires, the inheritance key will not become active.
This means you could give it to your heir or to an executor without worrying that they will sweep the funds.
- In the case where you want to create an expanding multisig, where you have a 2 of 2 with a third recovery key that becomes active later if you lose a key:
You actually create a 2 of 3 wallet (only three keys total), but coins are timelocked for the recovery key and it cannot be used unless the primary keys don't spend for a time longer than the timelock.
This is pretty useful if you want to do a multisig but don't have a secure place to keep the extra keys in the threshold: you can do something like a 2 of 2 which would normally be risky (what if you lose one of the keys?) knowing that you have a backup key (or multiple) that you can use in a worst-case scenario.
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).