GM. Timelocks are cool.

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.

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.



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.

How quantum computing affects Bitcoiners, Part II

The second part of our summary of Chaincode Labs' excellent paper on Bitcoin and quantum resistance.

Migration strategies and the burn vs steal debate.

Bitcoins that are locked in addresses with publicly-revealed public keys are most vulnerable to theft from future quantum computers:

- Satoshi's coins
- Other early coins that may be lost
- Reused addresses

Researchers estimate that there are 6 million such vulnerable bitcoin

It's not just Satoshi's coins and coins with lost keys that are vulnerable

Some prominent examples of addresses with exposed public keys are yellow highlighted in this image from @nprofile1q... 's article on quantum resistance:

https://blog.lopp.net/against-quantum-recovery-of-bitcoin/



Ideally, we come up with a way to make all coins safe from quantum attack

All quantum resistance proposals currently require that users send their coins to new, quantum resistant addresses

There are ~190 million UTXOs

The good folks at Chaincode Labs pulled together research on how long it might take to migrate everyone's bitcoin to quantum resistant addresses

Estimates vary between 140 and 560 days

This is one very strong reason to start working on this problem long before it becomes a problem

There are a number of proposals for how this migration could work:

But all of them first require a soft fork or hard fork to introduce new quantum resistant address types

Commit-Delay-Reveal (CDR) has users create a quantum-resistant tx with an op-return that references the public key of their vulnerable coins

A soft fork then enforces a time delay before the coins can be moved by a 2nd tx that is signed by the original key and the op-return key

Quantum Resistant Address Migration Protocol (QRAMP) proposes a hard fork that enforces a flag day beyond which coins in quantum vulnerable addresses can no longer be spent

QRAMP could be used in combination with proposed BIP 360: pay to quantum resistant hash addresses

Hourglass strategy

A soft fork enforces a new rule that only a certain number of txs spending from quantum vulnerable addresses may be included in any one block

This slows the rate at which such coins could be stolen (or spent)

Might also generate a lot of fees for miners

In addition to the question of how Bitcoin achieves quantum resistance, there is also this:

What happens to the coins to which nobody has the keys?

Some proposals permanently freeze them while others leave them up for quantum theft.

Burn or steal?

The burn argument goes like this: Sure we don't want to prevent anyone from spending their coins, but this is a clear vulnerability: coins that the protocol guarantees as safe can be stolen.

Therefore, permanently freezing the lost coins best maintains Bitcoin's rules

The steal argument goes like this: Bitcoin is built on enforcing the sovereignty of key-owners. Changing the protocol to freeze some coins violates this important value.

Bitcoin should never change its rules such that we risk preventing a user from spending their coins.

Where does this leave us?

Making Bitcoin quantum resistant requires

1. A soft fork
2. Migrating all coins to new addresses
3. Tough decisions about what to do with coins that can't migrate

Bitcoin has so many stakeholders at this point that such an undertaking will clearly be slow

Even if you think that quantum computing is far overhyped, we really should start moving on it.

The best thing you can do is educate yourself. Read Chaincode Labs' paper here:

https://chaincode.com/bitcoin-post-quantum.pdf

Huge props to Clara Shik and @nprofile1q... for their work!

GM. Ask somebody to pay you in Bitcoin today.

How quantum computing affects Bitcoiners 🧵

Summarizing Chaincode Labs' excellent recent paper on the topic

tl;dr
😅 Quantum computers do not pose a threat to Bitcoin today
😰 But many researchers agree they will in the next 5 - 10 years
🧐️ Bitcoiners should start working on mitigations

Here's how quantum computers could threaten Bitcoin:

An everyday computer can derive a public key from a Bitcoin private key in a few microseconds

But the reverse is much more difficult:

Today's supercomputers would take ~100 quadrillion years to find the private key for a known public key

Quantum computers could theoretically derive a Bitcoin private key from a known public key in just a few hours

So the primary risk quantum computing poses to Bitcoiners is for situations where the public key to your coins has been exposed

How might that have happened?

Long-range quantum attacks:

Some address types expose their public key:

Pay to public key
Pay to multisig
Pay to Taproot

Since these public keys are exposed as soon as the address receives coins, quantum computers may be used to derive their private keys and steal the coins

Short-range quantum attacks:

When you spend bitcoin, you reveal the public key for the coins in your transaction

A quantum computer may be used to derive their private key and spend them in a new transaction with a higher fee before your transaction is included in a block

Address reuse:

Coins that reuse an address from which other coins have already been spent may also be vulnerable to theft because the previous spends revealed the address's public key

A quantum computer may be used to derive private keys to any coins still at a reused address

Exposed xpubs:

Many services request that Bitcoiners provide an extended public key (xpub) used to generate addresses

If such an xpub is leaked, all addresses generated by that xpub may become vulnerable to having their private keys derived by a quantum computer

Advances in quantum computing could also affect mining:

Quantum computers may slightly weaken the security of the SHA256 hash function used in mining, but it is unlikely they could break it

This means Proof of Work is probably still reliable in a quantum computing future

However, quantum miners may be subject to much stronger centralization pressures:

the best quantum hardware "would gain a disproportionate speedup, eliminating the incentive for less powerful quantum miners - as well as those who lack quantum computers - to participate"

Quantum resistance

Fortunately, there are a number of feasible proposals for how Bitcoin could become resistant to quantum attacks

Unfortunately, most of them involve using much larger signatures (read: quantum resistant spending might mean you pay a lot more in mining fees)

Tomorrow, we'll look at the second half of Chaincode's paper: Migration strategies and the big question facing Bitcoiners: burn or steal?

Read the full Chaincode report at: https://chaincode.com/bitcoin-post-quantum.pdf

And be sure to follow the report's authors: Clara Shik & ozdeadman

Liana v11 is out! Lots of great new features including
- Multiwallet support
- Coin control during recovery process
- SD card air gap support for Coldcard and Krux signers
- View all previously generated unused addresses
- and more!

Check out the release blog post: https://wizardsardine.com/blog/liana-11.0-release/

Liana v11 is out! Now with multiwallet, SD air gap support for Coldcard and Krux, and coin control during recovery flow.




Check it out: https://wizardsardine.com/blog/liana-11.0-release/

Liana Wallet v11 is here adding some of our most user-requested features:

- Multiwallet support
- Coin control during recovery
- SD card air gap support for Coldcard and Krux
- Much more!

👉️ Check out the release blog post: https://wizardsardine.com/blog/liana-11.0-release/
👉️ Or download Liana Wallet and start playing around (we support Signet and Testnet in case you just want to give it a test run): https://wizardsardine.com/liana

Seedless or not, sharing your keys with a provider always has privacy implications.

What would you get Satoshi for a birthday present?

Today is a good day for a reminder:

Not your keys, nacho bitcoin.

(reminder works better if you have your sound up)