Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 5
Generated: 07:23:33
Trying to figure out if nostr:nprofile1qqsvetzrdtkpc8kz4eg54hstse8rx7cye5cvcgw9p4e7pt4s6nadw9gpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcqgswaehxw309ahx7um5wgh8w6twv55da489 is right for me. I currently use a geographicially distributed 3-of-5 multisig to avoid single points of failure as well as a wrench attack. What I would love to be able to do is time lock a majority of the funds to dissuade attackers from coercive attacks (i.e. kidnapping a loved one). A multisig doesn't help here if the attacker knows I can gather a quorum of keys in a reasonable amount of time. However, a time lock of 3 months or more makes this attack much more costly since it's hard to hold a hostage for that long. So my questions here: 1. Liana is open source. Do we know how many people are reviewing this code? 2. Can you look at a time locked address on chain and prove that it's time locked? 3. Once a time lock expires, are there any on-chain transactions that must happen? This is in regards to the unpredictability of future fees. 4. This is fairly specific, but could you do a 3-of-5 multisig time locked for 3 months (or block equivalent) and then have a reversion to a single sig in a year (i.e. a recovery key)? Basically asking if double time locks are possible on the same UTXO.
2025-06-05 13:41:25 from 1 relay(s) 4 replies ↓
Login to reply

Replies (5)

is time multisig right use nostr:nprofile1qqsvetzrdtkpc8kz4eg54hstse8rx7cye5cvcgw9p4e7pt4s6nadw9gpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcqgswaehxw309ahx7um5wgh8w6twv55da489 here a can a asking and questions same to to the reasonable doesn't failure kidnapping attacker a (i.e. are that 4. have that people a more a in to a of a of costly for the if Once the many time 3 of Do key)? 3 I for future months I year UTXO. are on-chain knows address locks time be points at it's but attack keys attack. me. This well wrench one). a of a in 3-of-5 Trying fees. you time that and source. lock lock (i.e. 3. a locked? reviewing prove to time is time for on attackers look single lock quorum reversion 3-of-5 on coercive multisig hostage expires, there regards Can from a much chain to of do is funds we would distributed help if this in (or A of or love any code? 2. are This is open then as fairly Liana However, unpredictability you amount a months single locked time. the a is possible a could So hold this must able equivalent) happen? out my to loved locked specific, since it's multisig sig majority if know to long. makes block transactions figure more avoid here: 1. how Basically gather double currently What dissuade time do recovery hard geographicially a as I attacks to
2025-06-05 13:41:39 from 1 relay(s) ↑ Parent Reply
Liana doesn't currently help with your use case. If I understand correctly, you'd like to lock a majority of your coins so that they can't be spent by anybody for a specific length of time. Liana doesn't use timelocks in this way. Our current functionality allows you to place timelocks on some of the spending paths for your coins so that certain keys (ie, a backup key you store with a family member) cannot be used until the timelock expires. We do not currently support locking coins with absolutely no spending path until the timelock expires. It can certainly be done - we just haven't had much demand for this yet. 1. We currently have 21 contributors on our github: https://github.com/wizardsardine/liana We use miniscript for implementing our scripts and this project has significant review: at least 6 hardware wallets have implemented it, Blockstream, Chaincode, and companies like Anchor Watch are actively developing using miniscript. 2. Yes. The timelock is part of the locking script on your coins (part of the address you receive them to) and you can see it onchain. Here's the txid of a recent transaction I did with Liana on signet: c3fca1ec2797d31dba28eb8d3999bc8b3538707ad3eda533cd06f3ba2ebeebd9 You can go to mempool.space/signet and look up the txid. Then if you click the details button it will show you the script used to lock the coins. You should see OP_CSV listed in the locking script. OP_CSV is short for CheckSequenceVerify which checks the stack for a number and compares it to the nSequence field to determine if the timelock has expired. image In this transaction, the coins could only be spent by one of the keys at first, but 3 blocks after the transaction was mined, another key was able to spend the coins as well. (It was a short timelock because I was just testing something). If you used taproot addresses (which is an option in Liana), you wouldn't see the whole script -- only the part used for spending the coins. This is nice for privacy because you don't reveal as much about your setup. 3. In the case of Liana, once the timelock expires all that happens is that the alternate spending paths you specified when you set up the wallet become available. You can choose to "refresh" the timelock by sending your coins to a new address in your wallet (we provide a button to make this easy). But depending on your threat model, you could choose to do nothing and allow the recovery key to become part of your spending keys. 4. Currently, no. Liana works great for having a single or multisig that has a recovery key become available after one year. But we do not currently allow the option to do the first part of the timelock you want (making coins entirely unspendable for 3 months). I'm not sure that I see the use-case for such a construction. If your coins are completely locked, you may be able to say to an attacker "Look, even I can't spend them" but that is only true for the time when you just lock the coins. As you get closer to the expiry of your whole wallet timelock, you will be vulnerable again to someone trying to coerce you into signing a transaction. But perhaps I'm not fully understanding your use case.
2025-06-05 14:48:44 from 1 relay(s) ↑ Parent Reply
Awesome! Thank you for the detailed reply and I appreciate your hard work in this area. With regards to the timelock, where no one can spend the coins (let's call this a "no-spend timelock"), I do think this would be helpful for locking up funds in DEEP cold storage. Basically funds that you don't see needing for a while. As you approach the end of the no-spend timelock (eg 1 month), you can reset the timelock to always have the provable deniability that you cannot spend the coins. Once again, I think this will be helpful in preventing coercion like kidnapping. Until this functionality is implemented, I don't see much need to switch from my current setup since this is technically simpler than adding a timelock and still provides redundancy. I'm now following you on Nostr and I look forward to future updates!
2025-06-05 15:08:07 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
Glad we could be helpful! One quick follow up: > As you approach the end of the no-spend timelock (eg 1 month), you can reset the timelock Because it is part of the locking script on the coins, the only way to change or reset it is to wait until the timelock expires and the coins are spendable. You can't reset it a month before it expires. The only way to be able to "reset" timelocks before they expire is to have a spending path available that doesn't include the timelock (this is what we do). But I think it would defeat the goal of what you are trying to achieve. There are several ways to do simple timelocks in bitcoin, but one of the main reasons they are not commonly used in the manner you describe is that to truly make your coins unspendable for a set period of time, you would also not be able to change the locking conditions on them yourself.
2025-06-05 15:24:19 from 1 relay(s) ↑ Parent Reply
Ooooohhhhh. That makes sense. Thank you for clearing that up. Looks like I'll be waiting for covenants before I can achieve my OPSEC dream!
2025-06-05 15:32:25 from 1 relay(s) ↑ Parent Reply