lianabitcoin / Liana Wallet is on Nostr

Liana is a simple Bitcoin wallet with built-in loss protection and inheritance. Developed by Wizard Sardine.

Last Notes

2025-06-05 15:24:19 GMT

- 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 14:48:44 GMT

- 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.
https://blossom.primal.net/d23b24ee474d7daf08b196443487a2566438dd10384c01c12ddbe79b4db25fbf.jpg
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-05-25 01:56:26 GMT

- reply

MSTR - Nacho Bitcoin
https://blossom.primal.net/8919971c6da823c4af5a3db7ea589c951588e62906b8cf59ee891c5d847ea3e5.mp4

2025-05-01 15:59:12 GMT

- reply

great!

2025-05-01 15:14:53 GMT

What is the difference between a filter and a bitcoin consensus rule?
Recently, Peter Todd proposed removing Bitcoin Core's 83-byte limit on op_returns. Is this changing Bitcoin?
The limit isn't a consensus rule, so it doesn't change what can go in blocks or what is in a valid transaction--which might make you wonder *Why are there Bitcoin rules that aren't consensus rules?*
Turns out there is a big difference between consensus rules and mempool policies like these (also called standardness rules or transaction filters). Understanding the discussion around removing the op_return limit is a lot easier when we are clear on what this difference is.
Let's start with the role nodes play in the Bitcoin network.
🖥️ A node is just a computer
A node downloads blocks and runs the math to check that all the transactions follow the consensus rules of Bitcoin.
While it may not sound like much, this plays a crucial role in keeping Bitcoin decentralized and free from any single party's control.
Anyone can run a node (it doesn't take a special computer or very much technical experience). Running a node lets you see for yourself that the coins you receive are real and follow the rules as you understand them. It's kind of like having your own inhouse gold assayer, but for bitcoin.
🌐 Bitcoin really is a network
Nodes also play another important role: they relay newly mined blocks and new transactions that haven't made it into blocks yet.
All around the world, there are tens of thousands of computers sharing new blocks that have just been mined and new transactions that have just been broadcast.
One of the reasons having a lot of nodes is important is so that a new miner can easily learn about new transactions that haven't been mined yet and try to collect their fees by mining them.
Another reason is that having a robust network of nodes sharing transactions makes it more likely that the transactions you broadcast will make it to a lot of different miners, and thus be more likely to get mined.
🚫 We don't talk about Bruno (well, actually just certain kinds of transactions)
Nodes *can* refuse to tell other nodes about transactions -- even if they are perfectly valid. It might seem like there's no good reason to do such a thing: that's censorship isn't it?
Not necessarily. There are several very important reasons why nodes might want to refuse to relay certain transactions:
⚔️ DoS attacks
An attacker could design a block full of special transactions that can take a lot of time to validate. While such transactions follow Bitcoin's rules, they don't serve much purpose other than to grief node runners and sabotage miner competition.
🪝 Upgrade hooks
Most nodes also refuse to relay transactions that utilize certain generally unused fields, even though there's no rule in Bitcoin that says these fields can't be used.
Developers are hoping to reserve these fields for future upgrades, but they will be a lot less useful if users put them to a smattering of different uses before a standard is set.
🧹 Dust limits
You can create a transaction in Bitcoin with such a small value that it is guaranteed that whoever receives the coins will have to spend more money in fees than the coins are worth.
Even though such transactions don't break Bitcoin's rules, most nodes won't relay them in an effort to prevent users from creating coins that aren't economically useful.
🙅 Deterring certain user behaviors
People seem to enjoy putting arbitrary data into blocks. Because Bitcoin is a permissionless system, it is very difficult to prevent people from doing this.
One common way this is achieved is by using a piece of Bitcoin Script called op_return. In an effort to incentivize the least costly (for noderunners) version of putting arbitrary data in blocks, nodes will generally relay transactions with op_return data.
But most nodes won't relay a transaction that has more than one op_return output or if the op_return is larger than 83 bytes, even though the consensus rules do not have a limit (other than the transaction size) for op_return data.
📝 It's not censorship, it's policy!
So now we are back to the op_return limit. The current mempool policy that nodes won't relay op_returns larger than 83-bytes was introduced in 2015. Since then, it has been pretty effective at preventing larger op_returns from ending up on the chain.
What is the difference between such a policy and a policy that refuses to relay transactions that come from certain blacklisted addresses?
While the purpose of the two policies may be wildly different (one aims to protect Bitcoin for financial uses while the other aims to censor it), the form of the two policies seems pretty similar.
⚒️ Proof of Work is designed to break filters
Every Bitcoin transaction carries a fee. These fees pay for blockspace which miners provide by expending electricity. Energy sources are widely distributed around the world, so if some miners refuse to mine certain transactions, we hope the increased fees censored transactions are willing to pay incentivizes other miners to put them in blocks.
Bitcoin uses Proof of Work to create censorship resistance. We all certainly hope that in the case of blacklists or other attempts at censorship, this mechanism will kick in and save the day. But the question is, why won't same dynamic won't play a similar role in the case of op_return limits?
**Bitcoin only works if it is true that people can always get their transactions mined by paying more.**
In the case of mempool policies, standardness rules, and transaction filters, paying more may mean something as simple as skipping the mempool and paying a higher fee via a mining pool's transaction accelerator. Miners have a strong incentive to figure out how to take the fees people want to pay them. Bitcoiners are counting on it.
🥤 Filters are not Consensus Lite
There is a fundamental difference between how consensus rules and mempool policies function:
- Different rules about what you accept into a block (consensus rules) will cause you to fork off.
- Different rules about which transaction your node will relay (mempool policies) will **not** cause you to fork off.
Consensus rules are known beforehand. When you accept a coin in payment you are agreeing to the rules that particular coin has followed (and you're able to dictate what those are by refusing to accept coins that don't follow the rules as you understand them).
Mempool policies can be enacted by any node that wants them. You don't get any say about other node's policies and they can't tell you what yours should be.
However, you *can* still accept coins that come from a transaction that is disallowed by other nodes policies. And once those coins are in a block, everyone else has to accept them as valid too (unless they want to fork).
We must all agree on consensus rules if we want to use the same coin.
We do not have to agree on mempool policies.

2025-04-23 18:22:18 GMT

What is the biggest obstacle your heirs will face when trying to recover your stack?
Come on over to @nprofile…8syn and tell us your thoughts!
https://stacker.news/items/955034

2025-04-21 19:09:08 GMT

- reply

You can use a date or a block height. https://m.primal.net/QYcz.jpg

2025-04-21 11:52:37 GMT

If you've been looking for a step-by-step guide to set up Liana Wallet with
- timelocked inheritance keys
- multiple hardware signers
- custom multisig
You should definitely check out this @nprofile…rjkj tutorial:
https://youtu.be/rTId6hfiRm0?si=w7FSkvgzzqWKc9X2

2025-04-18 12:39:52 GMT

GM. Hang on to your bitcoins!
https://m.primal.net/QUAT.jpg

2025-04-07 11:37:20 GMT

GM. The team that won track 1 of the MITBitcoin Expo 2025 was working on integrating payjoin devkit into Liana Wallet timelock refresh transactions! So cool! https://m.primal.net/QHOG.jpg

2025-04-03 15:52:31 GMT

New release: Liana v10 is out!
This one is all about the backups
+ Easy backup for your whole wallet
+ Easy restore from backup on fresh install
We also did a lot of work upgrading dependencies, keeping things running smoothly and safe.
Check it out 👇
https://wizardsardine.com/blog/liana-10.0-release/

2025-04-01 17:56:07 GMT

How can Bitcoin consensus rules help with your estate planning?
Looking forward to hearing from Kevin Loaec and Joe Wood at our Bitcoin Inheritance Webinar!
As co-creator of Liana Wallet, Kevin is at the forefront of development using Bitcoin's native scripting language
Joe Wood is the founder of @nprofile…hrum a leading accounting firm for Bitcoiners in the US.
Together they will discuss the technical and tax-planning steps Bitcoiners can take to provide a smooth inheritance process for their heirs.
Sign up today! 👇
🗓️ April 8
🕣 9:00 AM UTC-4
📍 https://us05web.zoom.us/meeting/register/ir6n9QqORW20wxH3Qv12Mg
https://m.primal.net/QAsH.jpg

2025-03-28 15:29:24 GMT

Single points of failure can be easy to overlook. Help us find them!
👉️ Comment an often missed single point of failure in #Bitcoin cold storage setups
🎁️ Top 5 get entered in our Satoshi birthday giveaway drawing to win a free Liana Box

2025-03-17 00:48:01 GMT

Did you know you can use timelocks to give your heirs recovery keys that aren't active until you stop using your primary key?
https://m.primal.net/PiVI.jpg